[whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Matthew Raymond]

Ian Hickson wrote:
> My current thinking is to have an attribute on the <menu> to distinguish 
> the type of menu, from a list of three types: context menu (hidden until 
> activated), tool bar/menu bar/menu button/whatever you call it (turns each 
> command into a button, and each submenu into a menu button), and the 
> default, which is to display as a <ul> (like today).

   I don't know, I kinda like having separate markup for menus and menubars:

| <menubar>
|   <!-- Note: Sibling Association Used. -->
|   <menulabel>Menu Label 1</menulabel>
|   <menu/>
|
|   <menulabel>Menu Label 1</menulabel>
|   <menu/>
|
|   <menulabel>Menu Label 1</menulabel>
|   <menu/>
| </menubar>

   Part of the benefit of this system is the ability to call menus that
are outside the <menubar>:

| <menubar>
|   <menulabel for="extMenu1">Menu Label 1</menulabel>
|   <menulabel for="extMenu2">Menu Label 2</menulabel>
|   <menulabel for="extMenu3">Menu Label 3</menulabel>
| </menubar>

   I'm a little shakey on the use case, but it seems useful.

   For toolbars, something similar to <menubar> that takes <button> or
<menulabel> children seems in order. I prefer doing this as opposed to
<menu type="menutype">, especially since <input type="[type]"> has
receive some resistance. It also creates specific elements they have to
support rather than attribute values, which makes it harder for vendors
to falsely claim support. I think it also increases visibility.

   Thought: Is the distinction between a menubar and a toolbar entirely
presentational? Use one element? <commandbar>?

   If you notice, my version of <menulabel> is both a menu label and a
menu button. Aside from situations where you have floating, persistent
menus with per-character styling in the title, I don't see a need for
the two concepts to be separate. Is there even a significant use case
for <menu> to have a |label| attribute? Seems to me that all menus made
visible by an input event. You may be able to see items in menu /bars/,
but in all other situations, you're clicking on a button or right clicking.

   Not sure I like the whole thing about the user agent guessing it's a
menu based on if it has a label or is connected to a context menu
reference. Might just be able to fix that by requiring the |label|
attribute. Then again, it seems like it's doing what could be done with
the |title| attribute. Perhaps an attribute |type| with the possible
values "menu" and "list", where "list" is the default.

   Then again, toolbars often have separators, so maybe they're a type
of list anyways and require <li>-type markup, thus making <menu type>
more appropriate. Hmm...

| <menu type="list|menu|commandbar">

   Above, the type "menu" is assumed to be a sort of context menu
activated either by a true context menu feature or by a <menulabel>.
Then again, <commandbar>-type elements are flat, and while they may have
groupings/separators (for toolbars, at least), they don't have
multilevel groupings.

/me trails off into deep thought...