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 new syntax: <menu type="context"> <menuitem type="" label="" ...> ... </menu> The behavior of <menuitem> is similar to <command>. However there is no need to use <menuitem> in <head> There are plans to upgrade the syntax in future to: <head> <command id="foo" type="" label="" ...> </head> <body> <menu type="context"> <menuitem command="foo"> </menu> </body> So <menuitem command="foo"> will synchronize relevant attributes with <command id="foo"> The new IDL interface MenuItemElement inherits from CommandElement.
What problems would this solve?
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html The syntax is similar, except that <command command=""> looks strange.
Ah, so it's solely a matter of not liking the current name. Ok.
It is not only about not-liking the current name, but to have more reasonable structure for menus, and keeping <command> elements as abstraction of a, well, generic command.
What problem does this solve? I don't understand. This seems quite silly.
It's a lot more clear to have the meaning of an element depend on its name, rather than its name and its context. In the example in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html the <command> element has three distinct meanings: 1. Create actual command which can be triggered using various UI features 2. Create a menu item 3. Create a toolbar button As a result, the markup looks terribly confusing. Why does the <command> in the menu have to refer to another <command>? How and why are they different? Can a <command> in a menu refer to a <command> in a toolbar? The markup in that example would be a lot easier to understand if it looked like: <head> ... <command id="copy" label="Copy" onclick="copy()"> <command id="cut" label="Cut" onclick="cut()"> <command id="paste" label="Paste" onclick="paste()"> </head> ... <toolbar> <button command="copy"> <button command="cut"> <button command="paste"> ... </toolbar> <menu type="context"> <menuitem command="copy"> <menuitem command="cut"> <menuitem command="paste"> ... </menu> <accesskey command="copy" key="meta c"> <accesskey command="cut" key="meta x"> <accesskey command="paste" key="meta v"> ... <toolbar> <button command="paste"> ... </toolbar> I'd also be fine with a separate <toolbarbutton> to separate from normal form <button>s. Additionally, if there's an error in the code that outputs the markup such that nesting is a bit wrong, you end up with elements that still have the right semantics (though they might no longer work properly due to having the wrong parent), rather than drastically change their semantics since they now have a parent of a different type. I don't see what trying to abstract all forms of UI into a single <command> element gives us?
mass-moved component to LC1
I don't understand the difference between a "command", a "menu item", and a "toolbar button". Aren't they all just different ways of presenting the same thing? What's the graceful degradation behaviour of <menuitem>? With the way the spec is written, you can write a menu or toolbar like this: <menu type="..."> <a href="/">Home</a> <button onclick="save()">Save</button> <label> Shapes: <select onchange="insertShape(this.selectedOptions[0])"> <optgroup>Insert <option>Rectangle <option>Circle <option>Triangle <select> </label> </menu> ...and in legacy UAs it would render as suggested by the markup above ignoring the <menu>, and in a <menu>-aware UA if type="context" it would create a menu that, when displayed, looks like this: ,---------. | Home | | Save ,-----------. | Insert >| Rectangle | `---------| Circle | | Triangle | `-----------' ...and if type="toolbar" it would create a toolbar that, when displayed, looks like this: [Home] [Save] [Insert v] |Rectangle | |Circle | |Triangle | '----------' <command> is just a way to add commands to these menus in a way that does not interfere with legacy UAs. It also, in the future, will allow us to add a way to reference commands from other elements, e.g. maybe <a command="home">Home</a> would create a link which, when clicked, would invoke the <command id=home> command's onclick="" handler. I just don't see why we'd have a <menuitem> element in this world.
This might be a bit off topic ... There's a hyperlink in your menu example: <menu type="toolbar"> <a href="/">Home</a> </menu> I'm curious how it should render, there's an example in "4.10.17 The meter element" section: <menu type="toolbar"> <a href="?cmd=hsg" onclick="hideSuggestedGroups()">Hide suggested groups</a> </menu> and it's rendered as a hyperlink I thought that every element that defines a command should render as a button when the menu is in the toolbar mode
The example in question assumes that there is some CSS that is restyling the toolbar somehow. How to do this is currently undefined, but we really should define it.
First of all, what is the utility of being able to switch between between a context menu and a toolbar by just flipping an attribute? Can you site any websites or applications that would have been easier to develop using such a capability? Or to put it another way, what would the downside be of having separate <menu> and <toolbar> elements? In fact, I would imagine that websites will have a harder time creating toolbars if they have to worry about some UAs rendering them as a menu instead of as a toolbar. Second, fallback hasn't been terribly successful in the history of HTML, especially in recent years when sites are very concerned about having a large degree of control of the visual appearance of websites. How many sites use actual fallback for <video> as opposed to using a library which does feature detection and then creates different DOMs depending on if <video> is supported or not? And in this case <video> is a lot simpler than <menu> since <video> is just a single UI "thing". In the example in comment 8, you would most likely want dramatically different rendering rather than simply using a fallback DOM with some CSS sprinkled on top. It seems to me that the markup elements of HTML that has been the most successful are the ones that has corresponded to a clear visual rendering. For example <ol> and <h1> has been a lot more successful than <address> and <abbr>. Trying to abstract away the rendering completely doesn't seem like it's going to be successful. It just appears to me that it's adding complexity without actually making it easier for sites to deploy the new elements as the simple fallback won't be satisfying their requirements anyway.
<menuitem> is no longer on track to being a void element, right?
I don't think you typically would switch from a toolbar to a context menu dynamically, but the two are semantically more or less identical and so it doesn't make sense for them to use different markup. You _are_ likely to use very similar commands in both; having different markup for one than the other arbitrarily makes this harder to do. The <command> vs <menuitem> discussion isn't about fallback, though certainly other parts of the feature are designed to use fallback and I think that's a good thing even if some authors go out of their way to do fallback themselves with sniffing, it's still good for their to be some sort of "automatic" fallback for cases where the author didn't bother. In conclusion, I really see no value in a <menuitem> element here.
The value is much more understandable markup, as well as markup which is easier to style or otherwise deal with. For example if you want to use XBL to render menuitems yourself you can do that more easily if menuitems all have the same name. I'd likewise ask the opposite question. What's the benefit of using the same element name for something that has dramatically different rendering? The fact that <input> does has been more a source of annoyance than a benefit.
> The value is much more understandable markup I don't really see why <command> would be any less comprehensible than <menuitem>. Indeed, I probably would often suggest people use neither -- for example, if the command is just to follow a link, I'd suggest using <a>, and so on. > as well as markup which is easier > to style or otherwise deal with. For example if you want to use XBL to render > menuitems yourself you can do that more easily if menuitems all have the same > name. Changing <command> to <menuitem> doesn't prevent the menu items from being all manner of other elements as well, e.g. <a>, <button>, <select>, etc. So I don't see how that's the case. I don't really see how you'd ever style the menu via the DOM, though. The whole point is to make it render using platform-specific conventions, taking all the various HTML semantics and turning them into one consistent UI; if we were going to allow authors to style this, we'd probably just use pseudo-elements, as in: menu ::menu-item { color: yellow; background: navy; } menu ::menu-separator { border-color: white; } The menu construction algorithm really doesn't work well for something that styles the DOM directly (consider e.g. the separator collapsing, the merging into the UA menu, etc). > I'd likewise ask the opposite question. What's the benefit of using the same > element name for something that has dramatically different rendering? The rendering has no bearing on it. It's the same semantic. > The fact > that <input> does has been more a source of annoyance than a benefit. I'm not really convinced of that. It has actually been quite helpful in various ways: it makes it easy to introduce new input types, doesn't require regular parser changes, etc. In fact, as far as I can tell <menuitem>/<command> follow the same pattern as <input>: you can use them for commands, radio items, and checked items. If we were really trying to avoid the <input> design pattern, we'd have three elements, not one.
(In reply to comment #15) > I don't really see how you'd ever style the menu via the DOM, though. The whole > point is to make it render using platform-specific conventions, taking all the > various HTML semantics and turning them into one consistent UI; if we were > going to allow authors to style this, we'd probably just use pseudo-elements, > as in: > > menu ::menu-item { color: yellow; background: navy; } > menu ::menu-separator { border-color: white; } > > The menu construction algorithm really doesn't work well for something that > styles the DOM directly (consider e.g. the separator collapsing, the merging > into the UA menu, etc). > > I had something similar in mind ... The HTML5 context menu feature in Firefox is implemented using a menu builder interface that creates custom context menu items. Another builder can be implemented to construct native anonymous elements for toolbar menus. I have even a patch for that although it's not finished yet because we were not sure about styling etc. Using pseudo-elements sounds good to me. Actually it would work like the XUL tree widget which uses pseudo elements to style rows, cells, text, separators, etc.
Given that, and given the benefit of using consistent elements for consistent semantics, I really don't think introducing a new element here is a good idea. This is especially true since if we do introduce a new element here we'll end up having to introduce yet another new element for keyboard shortcuts, another one for toolbar buttons, and another one for the command indirection once we add that. This is IMHO a non-scalable solution. <command> provides a simple API that covers all these problems in a consistent way, without losing the ability to style the resulting content.
(In reply to comment #17) > Given that, and given the benefit of using consistent elements consistent elements? <menuitem>, <toolbar> and <command> (non-visual cases) would be consistent, IMO >for consistent > semantics, I really don't think introducing a new element here is a good idea. > This is especially true since if we do introduce a new element here we'll end > up having to introduce yet another new element for keyboard shortcuts, another > one for toolbar buttons, and another one for the command indirection once we > add that. This is IMHO a non-scalable solution. 3 elements isn't bad. Having those elements would make it clear what content author is trying to do. Also, easier to read the source code when you have <menuitem> than abstract <command>.
And if it was not yet clear, I'm not at all sure we should support using <a>, <select> and other random elements inside menu. This menu thing is effectively something new, and I wish browsers don't need to support some very awkward special handling for certain old element types inside menu.
If we don't add support for <a>, <select>, etc. then <menuitem>, <toolbarbutton>, etc. makes much more sense than <command>.
Not supporting the existing elements makes this feature far less interesting. The whole point here is to be able to gracefully augment what we have now.
Olli, Jan, this bug is waiting on your response to Hixie's comment #21: > Not supporting the existing elements makes this feature far less interesting. > The whole point here is to be able to gracefully augment what we have now.
(In reply to comment #22) > Olli, Jan, this bug is waiting on your response to Hixie's comment #21: > > Not supporting the existing elements makes this feature far less interesting. > > The whole point here is to be able to gracefully augment what we have now. Well, I think having just one element to declare a menu item is much easier to remember. Hixie, could you explain why the extended syntax is more interesting ? Maybe we should wait for feedback from authors and webkit developers.
It's not "extended" syntax. That's the point. It's the existing features of HTML, like <a>, <button>, <select>, etc, used for their existing semantics, in a way that can have graceful degradation in legacy UAs, and defined in such a way that they all expose a uniform front and can therefore be used to display a consistent UI either in context menus or in toolbars. Creating a new element for this is just unnecessary. (<command> itself is unnecessary here, but is interesting because it later will allow us to create commands that are defined once but exposed in multiple places via reference.)
you need some new element, or add attribute to existing elements, so that menu items can have icons.
(In reply to comment #24) > It's not "extended" syntax. That's the point. It's the existing features of > HTML, like <a>, <button>, <select>, etc, used for their existing semantics, in > a way that can have graceful degradation in legacy UAs, and defined in such a > way that they all expose a uniform front and can therefore be used to display a > consistent UI either in context menus or in toolbars. > > Creating a new element for this is just unnecessary. (<command> itself is > unnecessary here, but is interesting because it later will allow us to create > commands that are defined once but exposed in multiple places via reference.) Ok, so my personal opinion is what I already mentioned. If we add support for <a>, <button>, <select>, etc, then <menuitem> is useless. Otherwise <menuitem> is much easier to use. So the question is, do we want to support existing elements ? It seems that implementation in webkit got lower prioritty, they are not actively working on it.
(In reply to comment #21) > Not supporting the existing elements makes this feature far less interesting. > The whole point here is to be able to gracefully augment what we have now. I disagree. In practice, authors want full control over the appearance of toolbars, and I don't think authors will start using menu element until this issue is addressed. Furthermore, I don't think most of web app developers will end up using this fallback path. I agree with Jonas' points and support removing the fallback algorithm and just have menu, menuitem, and toolbar elements.
(In reply to comment #25) > you need some new element, or add attribute to existing elements, so that > menu items can have icons. The current spec describes how to apply icons to some of the existing elements (e.g. links) in a backwards-compatible way. (In reply to comment #27) > > I disagree. In practice, authors want full control over the appearance of > toolbars, and I don't think authors will start using menu element until this > issue is addressed. For toolbars, that's probably a fair point. Unfortunately, that's kind of blocked on the component stuff. It doesn't apply to the context menu aspect of this though. > Furthermore, I don't think most of web app developers will > end up using this fallback path. It's not a "fallback path". It's the main way of using the feature. It just happens to work well for fallback.
> > Furthermore, I don't think most of web app developers will > > end up using this fallback path. > > It's not a "fallback path". It's the main way of using the feature. It just > happens to work well for fallback. The feature appears designed the way it is in order to allow for fallback. If that is not the case, what is the advantage of the specced approach over using a dedicated <menuitem> element?
Designing features so that they have sane fallback is one of our core values. In this instance, it's not the only reason, though. It also makes it possible to reuse existing features without having to redefine them. For example, if we want to have a toolbar button or context menu item that opens a new window, we reuse <a href="" target=""> because we already have the semantics for that element all carefully designed. If we want a toolbar button that submits a form, we can reuse <input type=submit> or <button type=submit>, because they already have all the interaction with forms that we need. If we want a radio button, we can reuse <input type=radio> because again, we already have all the logic there. Similarly, we reuse <hr> for separators because that's the <hr> element's semantic. Etc.
the arguments for <command> over <menuitem> are convincing. command seems to have a lot to it, but when i think of <menu> i don't think of a nav bar, i think of the context menu, we have a trillion ways to make a nav bar and NO way to put things in the context menu. a lot of the confusion seems like it would be settled by making either <menu> a tag specifically for context menus or specifically for nav and a different tag for context menus. the things that someone might want for a nav bar (by this i mean your basic drop down menu bar) are different from the things someone might want for context menu (for instance i wouldn't want a 1024x768 image in my context menu, or even a UL/li i have a general idea of what i expect a menu item to look like in a context menu and i want the custom ones to look as much like that as possible) a nav bar on the other hand you expect a lot of markup, you expect it to be styled and have drop downs with <input>s, <li>s,<img>s, etc
This bug was cloned to create bug 17800 as part of operation convergence.
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: Let's revisit this in HTML.next. Note that <menu> and <command> are on the list of at-risk features for HTML5.
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-v2.html Status: Accepted Change Description: https://github.com/w3c/html/commit/c5bcf8f2e230bc2a35a86d5cd6b873821de6c0bb Rationale: adopted WHATWG change to remove <command> and introduce <menuitem>, see discussion at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038472.html