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

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:
<http://dev.w3.org/html5/status/issue-status.html#ISSUE-134>

The bug has also been re-closed for now:
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10831>

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:
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13305>

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.

Regards,
Macie


> 
> 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