[whatwg] <menu> and friends

[Ian Hickson]

I've just checked in a somewhat large redesign of how context menus work 
in HTML. It's much more similar, though not identical, to what Firefox 
implements. It drops the <command> element, adds a <menuitem> element,
introduces a <button type=menu> feature, and drops <menu type=toolbar>.

High-level overview:

* There's now three features of relevance here:

   1. Toolbars.

   2. Context menus.

   3. Pop-up menu buttons.

* Toolbars are nothing more than a <div> with the element name <menu>. 
There's no magic at all, no special content model, it's all CSS for 
styling, you use regular form controls to fill the toolbar.

* Context menus and pop-up menu button menus use <menu type=popup>. The 
only children allowed for these elements are <menuitem>, <hr> for 
separators, and <menu label=""> for submenus.

* <menu type=menu menu="id"> <menu type=popup id="id"> defines a pop-up 
menu button.

* <menuitem> has all the stuff that <command> used to have, including 
<menuitem command="foo"> to point to another element (e.g. an <a href>, 
<button>, <option>, etc) and accesskey="".

* <menuitem> is void (requires parser changes).

* <command> is entirely gone. (Actually, I renamed <command> to <menuitem> 
and made it so it's only allowed in <menu>.)

I would love input from implementors regarding whether this is something 
they are more interested in implementing than what came before.


On Wed, 28 Nov 2012, Ian Hickson wrote:
> 
> 1. Styling of toolbars and menu buttons is just not defined.
> 
> Toolbars could be a purely stylistic issue, to be solved either 
> exclusively by CSS, or CSS plus a component/widget binding model 
> (whatever solution we end up with for that).

I've made the type=toolbar state be a regular <div>-like context. Authors 
are on their own again for making toolbars for now.


> 2. Nobody is implementing it, in particular, the algorithm that converts 
> HTML elements into a menu structure seems unpopular.

I've dramatically simplified this algorithm. It now only consists of 
<menu>, <menuitem>, and <hr>.

(We can drop <hr> if people don't like that; it's actually redundant with 
the handling of <menu> without a label.)


> With type=button, CSS would apply to the <menu> and <menuitem> elements, 
> maybe with a limited set of properties applying. Long term, we look to 
> XBL or Web components or whatever for styling.

I haven't got a solution for drop-down button styling. The <menu> in this 
scenario is display:none, so I can't get any styles out of it to affect 
the styling of the drop-down menu. I'm open to suggestions for how to fix 
this; maybe the solution is to have something like:

   display: compute-style-but-do-not-render-anything-in-flow


On Wed, 28 Nov 2012, Eduard Pascual wrote:
> 
> I have put a first example on http://std.dragon-tech.org/mainmenu.png 
> All you can see there is doable with plain CSS and HTML. It doesn't even 
> use any CSS3 features. In fact, the whole thing works fine in IE8. As 
> Fred Andrews mentioned, menus are quite easy to achieve with no 
> scripting, as long as one stays within "hover-based" menus. Of course, 
> most of the buttons and items in the screenshot require JS to actually 
> do anything, but that's because of the app's own complexity. All the 
> stuff in that window should be pretty much accessible (everything in 
> there are ul's, li's, and img's with matching @alt and @title for the 
> toolbar, which contains only shortcuts anyway, and load's of @onclick 
> attributes that could be easily replaced by <a>'s with @href's on a more 
> "web-ish" scenario).
> 
> In summary, menu bars and tool bars are quite a solved problem

I don't think a pile of CSS should be needed for this, though, that's the 
problem. Let alone any JS:

> Now, here is when stuff gets serious:
> http://std.dragon-tech.org/contextmenu.png
> To be honest, I hate most of the code behind that with a passion... and I
> wrote it! I get paid for making stuff work, and thus I make stuff work, no
> matter what it takes.
> The context menu requires JS to display at all. It "overrides" the
> browser's native menu (which sometimes would be useful). There is a huge,
> empty, transparent div covering the whole iframe (the main area on the
> screen with the table on it) just so it can catch clicks and dismiss the
> menu. The "context menu key" (that nice thing between right Ctrl and the
> "Windows" key) doesn't do anything (doesn't trigger neither my menu nor the
> browser's) when the iframe has focus.
> Don't get me wrong, I quite love what I pulled off, and so do most of the
> app's users; but I loathe the truckload of crap code I have to feed the
> browser for everything to work as intended.

Ideally you should just have to describe your toolbar or context menu in 
HTML and be done with it.


> * A mechanism (most probably an attribute + a CSS pseudo-class, or maybe
> even recycling :hover) to show click-based menu bars some script-less love.

Traditional menu _bars_ are not something that I've solved with this 
update (specifically, the part where you click on one menu bar's label and 
then hover over to another label and the other menu opens). It's not 
entirely clear to me that freestanding menu bars are an especially 
important user interface widget in the context of a Web page or Web app, 
but if so, we should indeed address it.

The simplest way of doing it that I can see would be a new type of <menu>:

   <menu type=menubar>
    <menu label="File">
     <menuitem ...>
    </menu>
    <menu label="Edit">
     <menuitem ...>
    </menu>
   </menu>

Are any browser vendors interested in implementing something like this?


> * A mechanism to deal with context menus in a sane way. It all boils 
> down to UA's natively handling the showing and dismissing of the menus; 
> and maybe enabling a mechanism to define a default (did you noticed the 
> bolded option at the start of the menu on the screenshot? Yay, 
> double-clicking instead of right-clicking does invoke it, skipping the 
> whole "show the menu" step! ). That would cause it to work with any 
> native method the browser or platform already supports for displaying 
> context menus.

This is supported now (including the default styling thing, though in the 
spec model that's just a hint, you have to implement the default behaviour 
yourself if you want that to actually happen).


> As a user, I would hope any context menu implementation grants me the 
> ultimate control on which menu is used (native vs. app-provided).

The browser leaves that up to the UA at the moment, but see discussion 
below.


On Thu, 29 Nov 2012, Olli Pettay wrote:
> 
> I think we need to keep the contextmenu functionality, and I don't see 
> reasons to not to do it the way Gecko has it now (using <menu 
> type="context"> and <menuitem>).

As far as I can tell the spec differs in the following ways from what 
Gecko does now (based on my understanding of what Gecko does, not on 
thorough tests):

 - <menuitem command=""> is not supported in Gecko.
   This is just a missing feature, not a big deal. I've heard a lot of 
   requests for the indirection feature so I've left that in the spec, but 
   if it never gets implemented I'll eventually drop it.

 - <menu type=popup> is implemented as <menu type=context> in Gecko.
   This is an unfortunate incompatibility. I renamed "context" to "popup" 
   because it doesn't make sense to have <button type=menu menu=""> 
   pointing at a <menu type=context> since then it's not a context menu 
   but a drop-down menu. Since both context menus and drop-down menus are 
   also called "pop-up menus" I went with "popup". If there's too much 
   content depending on type=context let me know and I'll change it back.

 - Gecko doesn't support <hr>.
   I can drop this from the spec if people think it's not a good idea.
   You can do the same thing using nested unlabeled <menu>s (Gecko does 
   support that). It's a bit weird to require the nested elements in 
   simple cases, which is why I've left <hr> in for now.

 - Gecko's parser doesn't treat <menuitem> as a void element.
   I think we should treat it as void because otherwise it's really 
   verbose.

 - Gecko uses the first text node of the <menuitem> element as a label if 
   there's no label="" attribute.
   I don't see much point supporting this, especially if we make it void.

 - Gecko doesn't support contextmenu="" pointing at a <menu> child of a 
   <menu type=context> (popup, in spec).
   Per the spec now, the child would be a valid target of contextmenu="" 
   since its type="" defaults to popup if its parent is a popup <menu>.
   This is more of a side-effect of other stuff, not a big deal.

 - Gecko doesn't drop submenus with no label (it does drop items with no 
   label, at least in most cases, and seems to strip separators as the 
   spec suggests).
   This just looks like a minor issue in Gecko.

 - Gecko doesn't support <button type=menu menu="">.
   It's now as of today, so that's not surprising.


> In Gecko MenuItem inherits Command, so it has type, label, icon etc.
> We could merge those two interfaces.

Done.


On Sun, 23 Oct 2011, Eric Sh. wrote:
>
> I was trying out the HTML5 context menu in firefox and I saw that there 
> is no way(in the specs) to create an empty menu with only selected 
> context menu items in it.
> 
> So for example if I have an image element and I want to create a context 
> menu with the items: "Rotate" and "Share" - I have to ask the browser to 
> "Add" them to the regular context menu along with the ten other items 
> that are already there.
>
> This makes a bulky context menu when I only need those two items and it 
> is especially hurtful for user experience if the context menu is close 
> to the bottom of the screen and is moved above the mouse cursor.
> 
> I suggest adding a way to ask the browser to create a brand new context 
> menu with only those items.

Not showing the browser's own context menu items is a hurtful user 
experience as well; indeed, possibly a worse one.

However, the spec does allow the user agent to not add its own items if 
that is considered better. Browsers are encouraged to provide an override 
if they do that (e.g. shift-click brings up the full menu).


On Sat, 22 Oct 2011, Jonas Sicking wrote:
> 
> I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 on this a 
> while ago. So far no changes to the spec though.

I'm not sure I really agree with the premise of the bug. It points to this 
image as a reason for not showing UA context menu items:

   http://userexperience.evantageconsulting.com/wp-content/uploads/2010/08/html5-context-menu.png

...but that to me is a perfect example of why this is a misfeature. 
Where's "Inspect Element", for example?

I think it would make sense for browsers to skip the less important menu 
items (those that are accessible via the menus, for instance) when showing 
a context menu that the author is providing. (But then, I think it would 
make sense to not show those ever.) But for things that are only sanely
accessible via the context menu, I don't see why we'd drop them.


On Mon, 24 Oct 2011, Mark Callow wrote:
>
> Is there a way for the user to access the regular context menu? I could 
> imagine it being extremely irritating and even frustrating if one can't 
> access familiar and useful items like "Copy link location", "Bookmark 
> this page" or "Select all" because the author of some element on the 
> page has decided to redesign the context menu.

Indeed.


On Sun, 23 Oct 2011, Jonas Sicking wrote:
> 
> That would be a decision that the UA can make. In firefox we have 
> forever had an option to control whether websites can disable the 
> built-in context menus or not. Traditionally that has been hooked up to 
> the contextmenu event. We now have the same pref hooked up to honoring 
> this new attribute as well.
> 
> Another option would be to "hide" the default context menu items in a 
> sub-menu rather than fully disable them.
> 
> There's several good choices here. All we need is for websites to be 
> able to signal that they want their options to replace ,rather than add 
> to, the default menu options. What the UA decides to do with that 
> information is a UI decision.

I don't understand why the page should ever be able to remove items that 
the user agent vendor think are important enough to put in the context 
menu in the first place.


On Wed, 26 Oct 2011, Ian Hickson wrote:
> 
> The idea is to wait to see how authors use a feature before extending 
> it, so that we can see what authors actually ask for.
> 
> In this particular case, what would be of interest is e.g. the following:
> 
>  - Amongst authors who primarily target the set of UAs that implement the 
>    context menu feature, do they actually use it, or do they continue to 
>    avoid it? If the latter, is it because of the lack of a way to hide the 
>    UA features?
> 
>  - Do authors file bugs or send spec feedback asking for the UA menu to be 
>    disabled, once they start using this feature?
> 
>  - Do UAs feel pressured to hide the UA menu based on author or use 
>    feedback once pages using this feature are widespread?
> 
>  - In browsers that do support an experimental extension to disable the 
>    ability to show the UA menu, do authors take advantage of it?
> 
>  - In browsers that hide the UA menu, do users get confused when they 
>    can't get to it? Do those UAs feel pressured to show the UA menu 
>    because of this?
> 
> In general, there's also the need to not add features so fast that the 
> feature set in different browsers is completely different due to them 
> each implementing their own subset of the spec. This is one reason to 
> keep the spec growth slow.

The above information would still be helpful in determining whether we 
should add a "nodefault"-like feature to HTML menus. Hopefully with the 
new changes there will be more widespread implementations and we will be 
able to get this information.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'