RE: ISSUE-134 change proposals review - Part 1

Tab

Do you plan to update your ISSUE-134 change proposal?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
Sent: Wednesday, February 15, 2012 10:43 AM
To: Tab Atkins Jr.
Cc: public-html@w3.org
Subject: ISSUE-134 change proposals review - Part 1

The following is a review of your change proposal for ISSUE-134:
http://lists.w3.org/Archives/Public/public-html/2011Jul/0235.html

This review if provided in order to help WG members improve the quality of their change proposals and to ensure that the WG Chairs make their views known about the completeness of change proposals well in advance of moving the related issues to the survey stage.

First this Change Proposal, as submitted, is missing a Details section. This would likely repeat the Summary section, but for clarity it would be best to properly include a Details section.

> The stated problem should probably be solved with CSS, as it is an issue of presentation.

You provide no technical motivation for "how" the problem might be solved in CSS.  Demonstrating this even with a small example would make your argument stronger.  Since the opposing proposal is arguing that using CSS is not appropriate and/or too difficult this point may be a deciding item in a WG survey of the change proposals.

In addition to expanding on *how* the problem could be solved with CSS, it would be good to expand on the *why*.  You mention that it is "an issue of presentation", but tablists, much like menus or buttons, have both a presentation and a behavior. What makes tabs different?

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

You seem to be waffling on whether this problem could or should be solved in this version of HTML5.   Your argument would be stronger if you could give more technical reasons why a better HTML-solution might exist or if you provided rationale for this change being part of HTML.next.

You have not provided a technical description of the so called "<input> anti-pattern".  Providing some more technical information on why adding "additional semantics" is bad would make your argument stronger.

Elsewhere in your re-open request you state that several user agent representatives are not in favor of implementing the change proposal at: 
http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements
If you could provide actual evidence and technical rationale for those statements directly in your change proposal that would make your arguments stronger.  

In addition you should probably add information about the position of user agent representatives to the Rationale section of your Change Proposal to highlight this since it may be an important aspect of a survey on ISSUE-134.

Please let us know if you plan to update your 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

Received on Tuesday, 28 February 2012 19:57:37 UTC