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

[Lachlan Hunt]

Matthew Raymond wrote:
> Lachlan Hunt wrote:
>> Ian Hickson wrote:
>>> Pity about the <menubar> being necessary to get the <select> to disappear, 
>>> but I guess we need that...
> 
>    If we must exclude the use of actual menu bars, I'd prefer the following:
> 
> | <nav>
> |   <form ...>
> |     <menulabel>
> |       <menu>
> |         <select>
> |           ...
> |         </select>
> |       </menu>
> |       <button type="submit" name="menu">Foo</button>
> |     </menulabel>
> |   </form>
> | </nav>

The <menu> element seems superfluous here.  I disagree with the use of 
the <nav> element because this isn't a navigational menu, it's a command 
menu.

>    I'm not sure I like the whole <menubar> scenario. With <menulabel> 
> (as you will see below), certain child markup is ignored, whereas 
> <menubar> is actually changing the semantics of the child markup. 
> Overloading and selectively altering the semantics of elements should be 
> avoided whenever possible.

I don't believe my suggestion was altering the semantics of any element. 
  The intention was the use the semantics of existing controls in a way 
that can rendered as a single widget that performs the functions of both 
(selection and submission) to achieve the submit-on-activation behaviour 
required, with a very good, accessible fallback mechanism in current UAs.

>> <label>
>>    <button for="foo">Foo</button>
>>    <select id="foo">
>>      ...
>>    </select>
>> </label>
>> ...
> 
>    If you interpret <button> as being a form control, then in the former
> the <label> would be associated with the <button>, where in the latter
> it would be associated with the select. Personally, though, I think this
> makes more sense:
> 
> | <label for="foo"><button>Foo</button></label>
> | <select id="foo">
> |   ...
> | </select>

Yes, but it loses any advantage gained (if there is/was any) by having a 
common parent element for the button and select elements.  However...

>    The <button> is not associated with the <label> because the |for|
> attribute explicitly defines the association as being with the <select>.
> Therefore, <button> can inherit the <label> association without adding a
> |for| attribute to it.

What's the advantage of having the label element at all in this case? 
Why not just give the button a for attribute?

>    I think we should focus on how to create solutions that allow optimal
> fallback rather than trying to support a broad range of suboptimal
> fallback options.

I thought my suggestion was an attempt at providing optimal fallback.  I 
can't think of any cases where it would be suboptimal?

>    The <menulabel> would ignore the <button> in the same way I defined
> it as ignoring <a> elements. The contents are kept, but the element
> itself is ignored.
> 
>    Similarly, this is another solution:
> 
> | <menulabel>
> |   <menu>
> |     <select>
> |       ...
> |     </select>
> |   </menu>
> |   <button>Foo</button>
> | </menulabel>

Again, what's the point of the <menu> element?  And, the menulabel don't 
make sense.

>    For situations where the button isn't used, you can just drop it:
> 
> | <menulabel>Foo
> |   <menu>
> |     <select>
> |       ...
> |     </select>
> |   </menu>
> | </menulabel>

Without the button, I think it should just be an ordinary select 
element.  There would be no submission semantics (from the button) and, 
therefore, it doesn't really satisfy the semantics of a command menu.


After much though, I've refined my original idea and also gone back to 
Ian's original idea that navigation menus and command are the same 
structure, only differing in their functionality.

Each command menu is marked up like this:

<cmd>
   <select/>
   <button/>
</cmd>

or with the button and select switched:

<cmd>
   <button/>
   <select/>
</cmd>

or with input instead:

<cmd>
   <input type="submit"/>
   <select/>
</cmd>

(Other alternative element names for <cmd> could be: menuitem, 
commandmenu, cmdmenu, command, but I like cmd because it's short, easy 
to type and to remember.)

Also note that there doesn't need to be a for attribute to associate the 
  button with the select, as it's implicitly done with the cmd element. 
  It would need to be defined in a way that says the first select 
element is associated with the first button element (to handle cases 
where authors throw other extraneous markup within, including extra 
buttons/selects).

If there's just one command menu, that (with an associated form element) 
should be all the markup requried for a functional menu with good 
fallback abilities.  But, for the cases where it's more like a menu bar 
comprising several menus (e.g. File, Edit, View, etc.) they can be 
contained within a menu element:

<menu>
   <cmd/>
   <cmd/>
   <cmd/>
</menu>

(where each cmd contains a select and a button, as above)

Now, going back to the idea that navigational menus and command menus 
are the same structure, the menu element can be used for those too, 
except using <li> instead of <cmd>, much like people use <ul> today, but 
with a more semantically appropriate element.

<menu>
   <li><a>...</a></li>
   <li><a>...</a></li>
   <li><a>...</a></li>
</menu>

-- 
Lachlan Hunt
http://lachy.id.au/