In particular the following part of the spec really exposes why having a single element for both popups and toolbars is ugly:

"The missing value default is the popup menu state if the parent element is a menu element whose type attribute is in the popup menu state; otherwise, it is the toolbar state."

Nobody should need to check the parent of an element to figure out what the element is -- what it's for, what the purpose of the element is -- the element's semantics should be unambiguous just from examining the element itself.

If we had separate elements for popups and toolbars, none of the spec language around "missing value default" here would be needed, and all of unnecessary complications for Web authors and documentation writers and implementors would be eliminated.

Well, the toolbar version is literally just the old <menu> from the 90s.

<menu type=popup> is only required on the outermost menu, to make it invisible. That's the only reason for the prose you quote that you say is complicated. In practice I don't think it's not confusing at all. Tutorials don't need to mention this, they just need to say "and when you have a submenu, you don't need a type attribute, it's implied".

I agree that with the way the feature is currently specced the old benefits to reuse <menu> for menus are mostly gone. The main advantage now is just the element's name being so perfect, but that's kinda lost with the attribute on the outer one, granted.

We could rename <menu type=popup> to something else... I can't really think of anything that would be any more pithy, though.

(In reply to comment #2)
> Well, the toolbar version is literally just the old <menu> from the 90s.
> 
> <menu type=popup> is only required on the outermost menu, to make it
> invisible. That's the only reason for the prose you quote that you say is
> complicated. In practice I don't think it's not confusing at all. Tutorials
> don't need to mention this, they just need to say "and when you have a
> submenu, you don't need a type attribute, it's implied".
> 
> I agree that with the way the feature is currently specced the old benefits
> to reuse <menu> for menus are mostly gone. The main advantage now is just
> the element's name being so perfect, but that's kinda lost with the
> attribute on the outer one, granted.
> 
> We could rename <menu type=popup> to something else... I can't really think
> of anything that would be any more pithy, though.

Mint a new <submenu> element instead.

<submenu> wouldn't work for the contextmenu="" use case and the <button menu=""> use case. (It would work for the <menu type=popup><menu> use case, but that's the least problematic one, IMHO.)

(In reply to comment #2)
> Well, the toolbar version is literally just the old <menu> from the 90s.

Which is really nothing more than an alias for <ul>. But yeah I can see that for backwards-compatibility reasons, we can't change that.

> We could rename <menu type=popup> to something else... I can't really think
> of anything that would be any more pithy, though.

What about just <popupmenu> or <contextmenu>?

<contextmenu> would be better since we already have "contextmenu" for the global attribute. And menu@type=popup was originally type=context anyway -- and actually is implemented as type=context in the only UA that implements any of this.

And yeah I know what the rationale[1] for having type=popop instead of type=context is, but that doesn't seem to me like such a strong rationale. I think we could have a <button type=menu menu=""> point to a <contextmenu> element without doing damage to semantic purity.

But then I think <popupmenu> would be OK too.

[1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html
[[
<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.
]]

(In reply to comment #5)
> And yeah I know what the rationale[1] for having type=popop instead of
> type=context is, but that doesn't seem to me like such a strong rationale. I
> think we could have a <button type=menu menu=""> point to a <contextmenu>
> element without doing damage to semantic purity.

Data point: if you try to look up "Popup menu" in Wikipedia, it redirects to "Context menu":

  http://en.wikipedia.org/wiki/Popup_menu

"A context menu (also called contextual, shortcut, and popup or pop-up menu) is a menu in a graphical user interface (GUI) that appears upon user interaction..."

I think I'd be happier with finding a way to just dump the attribute than minting a new element with a long name like that.

(In reply to comment #7)
> I think I'd be happier with finding a way to just dump the attribute than
> minting a new element with a long name like that.

We could drop menu@type=toolbar completely and define <menu> as being what menu@type=popup is defined as now.

A document marked up with <menu><li>.. would be a document-conformance error. For the validator, I could have it emit a message saying "Using the ul element instead."

That could work. Do you have any visibility into how common <menu> is?

I meant in the validator, but actually, that's a non-starter, since we need to hide <menu> from the rendering and can't hide the legacy <menu>s (it's common in legacy pages).

I can't think of anything better than <menu type=popup> for the outermost self-hiding element of a context menu or drop-down menu definition.

(In reply to Ian 'Hixie' Hickson from comment #11)
> I can't think of anything better than <menu type=popup> for the outermost
> self-hiding element of a context menu or drop-down menu definition.

In the mean time, I've not thought of any new suggestions either.

I'll leave this open until implementations make this moot, in case we come up with a better name before then.

I don't feel strongly about this to keep it open. I (or somebody) can re-raise it at github if we want to re-pursue it in the future.