This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 13608 as part of operation convergence. Originally filed: 2011-08-03 14:25:00 +0000 Original reporter: Jan Varga <jan.varga@gmail.com> ================================================================================ #0 Jan Varga 2011-08-03 14:25:37 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #1 Tab Atkins Jr. 2011-08-03 14:35:35 +0000 -------------------------------------------------------------------------------- What problems would this solve? ================================================================================ #2 Jan Varga 2011-08-03 14:40:03 +0000 -------------------------------------------------------------------------------- http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html The syntax is similar, except that <command command=""> looks strange. ================================================================================ #3 Tab Atkins Jr. 2011-08-03 14:57:17 +0000 -------------------------------------------------------------------------------- Ah, so it's solely a matter of not liking the current name. Ok. ================================================================================ #4 Olli Pettay 2011-08-03 16:22:32 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #5 Ian 'Hixie' Hickson 2011-08-03 18:59:06 +0000 -------------------------------------------------------------------------------- What problem does this solve? I don't understand. This seems quite silly. ================================================================================ #6 Jonas Sicking 2011-08-03 21:20:14 +0000 -------------------------------------------------------------------------------- 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? ================================================================================ #8 Ian 'Hixie' Hickson 2011-08-20 19:15:39 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #9 Jan Varga 2011-08-20 20:00:46 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #10 Ian 'Hixie' Hickson 2011-08-22 22:17:08 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #11 Jonas Sicking 2011-08-23 06:17:09 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #12 Henri Sivonen 2011-09-06 12:01:25 +0000 -------------------------------------------------------------------------------- <menuitem> is no longer on track to being a void element, right? ================================================================================ #13 Ian 'Hixie' Hickson 2011-09-11 18:01:41 +0000 -------------------------------------------------------------------------------- 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
*** This bug has been marked as a duplicate of bug 17806 ***