This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18210 - Why is this an empty element with attributes label and icon? These two attributes should get deleted and content should be allowed that can be styled.
Summary: Why is this an empty element with attributes label and icon? These two attrib...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P2 enhancement
Target Milestone: ---
Assignee: Robin Berjon
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 17:41 UTC by contributor
Modified: 2016-04-20 16:23 UTC (History)
10 users (show)

See Also:

Attachments

Description contributor 2012-07-18 17:41:35 UTC 
This was was cloned from bug 17290 as part of operation convergence.
Originally filed: 2012-06-02 08:16:00 +0000

================================================================================
 #0   contributor@whatwg.org                          2012-06-02 08:16:35 +0000 
--------------------------------------------------------------------------------
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html
Multipage: http://www.whatwg.org/C#the-command-element
Complete: http://www.whatwg.org/c#the-command-element

Comment:
Why is this an empty element with attributes label and icon? These two
attributes should get deleted and content should be allowed that can be
styled.

Posted from: 93.206.129.217
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
================================================================================
Comment 1 Robin Berjon 2012-09-11 15:08:57 UTC 
There is logic in using a simple label and icon since this can appear in UI components that would typically not support more than that. Leaving it open in .next though in case there's value in having meaningful content that could be surfaced from a closer look.
Comment 2 Silvia Pfeiffer 2013-01-07 04:47:09 UTC 
Would appreciate feedback on a commit that I just adopted from the WHATWG, which removes the <command> element and replaces it with a <menuitem> element:
https://github.com/w3c/html/commit/c5bcf8f2e230bc2a35a86d5cd6b873821de6c0bb

Also see the discussion at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038472.html .
Comment 3 Robin Berjon 2013-01-21 15:58:27 UTC 
Mass move to "HTML WG"
Comment 4 Robin Berjon 2013-01-21 16:01:14 UTC 
Mass move to "HTML WG"
Comment 5 Andrea Rendine 2014-04-25 00:08:40 UTC 
The idea of having the element's textContent as command's label still remains. While the icon attribute is useful for some UAs, the very same level of functionality can be achieved via the element IDL attribute textContent, with the sensible differences that:
 a. the textContent is directly translatable
 b. the textContent is stylable
 c. the textContent also appears in those UAs which do not support the menu itself, but can be instructed to show it thanks to CSS (showing the attribute is somehow more difficult).
Comment 6 Axel Dahmen 2014-10-03 15:54:04 UTC 
Yes, and I also believe that the notion of a command being just a label and an icon is too restrictive. Just like a notion of a <select> element containing only a list of <option> elements providing only a label.

We now know that the original <select>/<option> notion has overcome its definition by now.

This is same for menuItem and all other kinds of elements that could be as easily be represented/replaced by a <ul>/<li> element combination.

There is no reason in creating new elements with such harsh restrictions if there are elements existing, serving the same semantical purpose already today.
Comment 7 Travis Leithead [MSFT] 2016-04-20 16:23:25 UTC 
HTML5.1 Bugzilla Bug Triage: Incubation needed

In general, the command infrastructure is still in its infancy. Yes we have stretched <select>/<option> and the like in different ways, however they still have good semantic meaning and are accessible. I wonder what the accessibility impact would be from your proposal (using the textContent). To develop this idea further, please start a discussion over in the WICG. Thanks!

This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).