ISSUE-134 tab-states: Reopened (was Re: ISSUE-134 tab-states. Objection raised after issue closed by amicable resolution.)

Hi all,

For the Task force's Information, Issue 134 tab-states was reopen:
http://lists.w3.org/Archives/Public/public-html/2011Jul/0285.html

Tab's counter change proposal:
http://lists.w3.org/Archives/Public/public-html/2011Jul/0235.html

Related decision policy bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13305

Best Regards,
Laura

---------- Forwarded message ----------
From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 20 Jul 2011 00:03:36 -0700
Subject: Re: CfC: Close ISSUE-134 tab-states by Amicable Resolution
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, Anne van
Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>


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
>





-- 
Laura L. Carlson


On 7/14/11, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
> Hi All,
>
> For the Task Force's information HTML ISSUE-134 tab-states was closed
> by Amicable Resolution.
> http://lists.w3.org/Archives/Public/public-html/2011Jul/0214.html
>
> However, after the HTML Chairs closed the issue an objection and
> concerns have been raised:
> http://lists.w3.org/Archives/Public/public-html/2011Jul/0220.html
> http://lists.w3.org/Archives/Public/public-html/2011Jul/0221.html
> http://lists.w3.org/Archives/Public/public-html/2011Jul/0222.html
>
> Best Regards,
> Laura
>
> ---------- Forwarded message ----------
> From: Paul Cotton <Paul.Cotton@microsoft.com>
> Date: Wed, 13 Jul 2011 15:10:32 +0000
> Subject: RE: CfC: Close ISSUE-134 tab-states by Amicable Resolution
> To: "public-html@w3.org" <public-html@w3.org>, "Ian Hickson
> (ian@hixie.ch)" <ian@hixie.ch>
>
>> If no objections are raised to this call by July 12th 2011, we will direct
>> the editor to make the proposed change.
>
> At this time, we find that we have consensus on the following proposal
> for ISSUE-134:
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements
>
> Bug 10831 will be REOPENED and marked as WGDecision.  Once the editor
> has made the change, ISSUE-134 will be CLOSED.
>
> /paulc
> On behalf of the HTML WG Chairs
>
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org]
> On Behalf Of Paul Cotton
> Sent: Tuesday, July 05, 2011 5:13 PM
> To: public-html@w3.org
> Subject: CfC: Close ISSUE-134 tab-states by Amicable Resolution
>
>> ISSUE-134 tab-states - 'Provide tablist and tab states for menu and
>> command elements respectively'
>>
>> The current status for ISSUE-134 is as follows:
>> http://www.w3.org/html/wg/tracker/issues/134
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-134
>>
>> We have a single Change Proposal to Allow menu and command to represent a
>> tablist":
>> http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements
>>
>> At this time the Chairs would also like to solicit alternate Change
>> Proposals (possibly with "zero edits" as the Proposal Details), in case
>> anyone would like to advocate the status quo or a different change than
>> the specific one in the existing Change Proposal.
>>
>> If no counter-proposals or alternate proposals are received by July 1st,
>> 2011, we will proceed to evaluate the change proposal that we have
>> received to date for ISSUE-134.
>
> As we have received no counter-proposals or alternate proposals, the
> chairs are issuing a call for consensus on the proposal that we do
> have.
>
> If no objections are raised to this call by July 12th 2011, we will
> direct the editor to make the proposed change.  If anybody would like
> to raise an objection during this time, we strongly encourage them to
> accompany their objection with a concrete and complete change
> proposal.
>
> /paulc
> HTML WG co-chair
>
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
>
>
>
>
>
>
> --
> Laura L. Carlson
>


-- 
Laura L. Carlson

Received on Wednesday, 20 July 2011 12:01:59 UTC