This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The menu element, along with the command element, can currently represent a menu, context menu, or toolbar. I propose that this functionality be extended to allow menu and command to represent a tablist (tabstrip) as well. Add 'tablist' state to menu element. Add 'tab' state to command element. Add 'tabpanel' state to command element. Add 'tabgroup' to command element. When a menu state is set to 'tablist' the menu represents a list of tabs. When a command state is set to 'tab' the command represents a tab. A command with state 'tab' must also have a tabpanel attribute set, the value of which shall be set to the id of an element in the document which represents the content (tab panel) of the tab. A command with state 'tab' shall indicate which tabgroup it is a member of by setting the value of the tabgroup attribute, only one tab within each tabgroup may be selected. User agents will only present as visible the selected tab from each tabgroup, the remaining tabs from each tabgroup will not be visible, or accessible to assistive technology.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: A tab box is just a different overflow presentation. It's not a semantic distinction. Thus this really should be done in CSS (or more likely, XBL driven from CSS).
(In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: A tab box is just a different overflow presentation. It's not a > semantic distinction. Thus this really should be done in CSS (or more likely, > XBL driven from CSS). You couldn't be more wrong. A tablist is 100% semantic, it conveys meaning about the purpose and role of a certain segment of the document.
I should not have said that this is 100% semantic. Clearly the behavior of hiding and showing content is visual. The ability to know that a region of the document is a tablist, and that it contains tabs, one of which is selected, is semantics.
The bug-triage sub team decided to add the a11yTF keyword. @Everett, could you please provide a use-case to explain the tablist-role of a menu or command element?
http://www.w3.org/html/wg/tracker/issues/134
Decision: http://lists.w3.org/Archives/Public/public-html/2011Jul/0214.html Change Proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements
Re-closing for now, given the new Change Proposal.
mass-move component to LC1