W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: CfC: Close ISSUE-134 tab-states by Amicable Resolution

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 20 Jul 2011 00:03:36 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>
Message-id: <DAE3AE4E-0563-46CA-828E-97A0DD4241B4@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Jul 14, 2011, at 2:12 PM, Tab Atkins Jr. wrote:

> On Thu, Jul 14, 2011 at 5:16 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>> First, thanks to Tab, Jonas, and Anne for your feedback on issue 134.
>> I'd like to draw your collective attention to the fact that we have a
>> long-standing policy[1] of allowing issues to be reopened based on new
>> information and a concrete change proposal.
>> I encourage each of you to consider submitting a change proposal on this
>> matter.
> Sure.  I'd like to submit a request to reopen.

Given the new Change Proposal, we are going to consider the issue still open. Here is the relevant issue status link:

The bug has also been re-closed for now:

However, in the future we will treat a closed CfC as a binding Working Group decision with the same weight as a survey decision, and therefore will only allow a standard issue reopen request as the remedy. Meaning, the original resolution will stand until and unless a new decision comes down. See this Decision Policy bug for details:

Informally, I would recommend integrating the new data directly into the Change Proposal as it will likely be found lacking in review down the line otherwise.


> New Data
> ========
> 1. The "Details" part specifies that "User agents must manage focus
> for the tab controls by ensuring that only the selected tab is
> focusable, and that the remaining tabs in the tablist menu are not
> focusable.".  However, the "Risks" section states without such an
> element, developers might make "only the selected tab in each
> tablist... focusable, meaning that the remaining tabs from each
> tablist will not be available or accessible to assistive
> technologies.".  Is this a good or bad thing?
> 2. In "Details", "tabpanel" is listed as a state for <command>
> elements, but later text seems to suggest that it should be an
> attribute on <command> elements that takes an IDREF.
> 3. The CP doesn't indicate what the proposed changes should *do*.  The
> intention is clearly to make it easier to do cardstacks, where you
> have a list of tabs associated with cards, and only one card is
> visible at a time (and its tab is specially indicated in the tablist).
> But nothing like that is specified anywhere.  It appears that authors
> would still need to use script to create this kind of UI.
> 4. This is fundamentally a CSS issue.  I've thought about this exact
> problem before, and while I suspect there *may* be something we need
> to do at the host-language level to connect tabs to cards, that
> conclusion should only come after some research has been put into the
> problem by the CSS Working Group.
> 5. An Opera representative has stated that Opera would not implement
> this proposal.  A Firefox representative has expressed doubts that
> this is an appropriate solution to the stated problem.  I (a Chrome
> developer) also believe this is not an appropriate solution to the
> stated problem.
> Counter Change Proposal
> =======================
> Summary
> -------
> No change.
> Rationale
> ---------
> The stated problem should probably be solved with CSS, as it is an
> issue of presentation.  If it is best solved in HTML, it is likely
> *not* through the provided solution, which overloads the <menu> and
> <command> elements with additional semantics, similar to the known
> anti-pattern exemplified by <input>.
> Benefits
> --------
> A bad solution is not adopted.  Work is not misspent on bad solutions
> that could instead be spent on investigating a good, CSS-based solution.
> Risks
> -----
> Tablists continue to be fiddly to implement in a fully accessible way
> for an extended period of time.  They've been that way for years,
> though, so this isn't a new issue.
> ~TJ
Received on Wednesday, 20 July 2011 07:04:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:15 UTC