Bug 13608 - Add <menuitem> element
Add <menuitem> element
Status: RESOLVED FIXED
Product: HTML.next
Classification: Unclassified
Component: default
unspecified
Other All
: P2 enhancement
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-03 14:25 UTC by Jan Varga
Modified: 2013-01-07 04:58 UTC (History)
19 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Varga 2011-08-03 14:25:37 UTC
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.
Comment 1 Tab Atkins Jr. 2011-08-03 14:35:35 UTC
What problems would this solve?
Comment 2 Jan Varga 2011-08-03 14:40:03 UTC
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html

The syntax is similar, except that <command command=""> looks strange.
Comment 3 Tab Atkins Jr. 2011-08-03 14:57:17 UTC
Ah, so it's solely a matter of not liking the current name.  Ok.
Comment 4 Olli Pettay 2011-08-03 16:22:32 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2011-08-03 18:59:06 UTC
What problem does this solve? I don't understand. This seems quite silly.
Comment 6 Jonas Sicking 2011-08-03 21:20:14 UTC
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?
Comment 7 Michael[tm] Smith 2011-08-04 05:02:16 UTC
mass-moved component to LC1
Comment 8 Ian 'Hixie' Hickson 2011-08-20 19:15:39 UTC
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.
Comment 9 Jan Varga 2011-08-20 20:00:46 UTC
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
Comment 10 Ian 'Hixie' Hickson 2011-08-22 22:17:08 UTC
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.
Comment 11 Jonas Sicking 2011-08-23 06:17:09 UTC
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.
Comment 12 Henri Sivonen 2011-09-06 12:01:25 UTC
<menuitem> is no longer on track to being a void element, right?
Comment 13 Ian 'Hixie' Hickson 2011-09-11 18:01:41 UTC
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.
Comment 14 Jonas Sicking 2011-09-26 04:09:07 UTC
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.
Comment 15 Ian 'Hixie' Hickson 2011-09-26 06:55:53 UTC
> 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.
Comment 16 Jan Varga 2011-09-26 07:56:08 UTC
(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.
Comment 17 Ian 'Hixie' Hickson 2011-09-26 21:00:41 UTC
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.
Comment 18 Olli Pettay 2011-10-04 10:02:26 UTC
(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>.
Comment 19 Olli Pettay 2011-10-04 10:11:29 UTC
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.
Comment 20 Jan Varga 2011-10-04 12:21:55 UTC
If we don't add support for <a>, <select>, etc. then <menuitem>, <toolbarbutton>, etc. makes much more sense than <command>.
Comment 21 Ian 'Hixie' Hickson 2011-10-06 00:27:32 UTC
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.
Comment 22 Michael[tm] Smith 2011-11-20 17:29:21 UTC
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.
Comment 23 Jan Varga 2011-11-21 11:54:27 UTC
(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.
Comment 24 Ian 'Hixie' Hickson 2011-11-21 22:39:09 UTC
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.)
Comment 25 Olli Pettay 2011-11-21 23:00:15 UTC
you need some new element, or add attribute to existing elements, so that
menu items can have icons.
Comment 26 Jan Varga 2011-11-22 10:23:51 UTC
(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.
Comment 27 Ryosuke Niwa 2011-11-30 01:10:36 UTC
(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.
Comment 28 Ian 'Hixie' Hickson 2011-12-07 20:02:09 UTC
(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.
Comment 29 Jonas Sicking 2011-12-07 20:21:36 UTC
> > 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?
Comment 30 Ian 'Hixie' Hickson 2011-12-07 20:29:12 UTC
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.
Comment 31 austin 2011-12-16 17:23:53 UTC
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
Comment 32 contributor 2012-07-18 04:37:32 UTC
This bug was cloned to create bug 17800 as part of operation convergence.
Comment 33 Edward O'Connor 2012-10-17 17:29:07 UTC
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.
Comment 34 Silvia Pfeiffer 2013-01-07 04:58:57 UTC
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