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

[Ian Hickson]

On Thu, 1 Dec 2005, Matthew Raymond wrote:
>>>>
>>>> <menu>
>>>>   <cmd>          <!-- Menu command item -->
>>>>     <button/>    <!-- [Label] for command menu -->
>>>>     <select/>    <!-- The menu items -->
>>>>   </cmd>
>>>>   <li>           <!-- Menu list item (e.g. navigational list) -->
>>>>     <menulabel/> <!-- Label for nav menu -->
>>>>     <menu/>      <!-- The menu items -->
>>>>   </li>
>>>> </menu>
>>>
>>> You're mistaken. The <button> caption actually isn't the menu label in 
>>> many cases.
>> 
>> Since the button itself wouldn't actually be visible in WA1 UAs, it's 
>> really only there for fallback, why can't it be used as the menu's 
>> label?
> 
> Because, semantically, it's not actually a label for the <select>. In 
> fact, semantically, the two controls are only related indirectly via the 
> <form>.

Well, they have semantic if we say they do. We could easily say in the 
spec that if a button and a select both are in an <li> of a <menu> with an 
attribute foopy with value barpy, that they are in fact related in that 
the <select> represents commands and the button represents the activation 
of the command and has a label that says can be used as a label for a menu 
button of the same set of commands.


> You could use the <button> as a menu label if the <label> is absent, but 
> the web author should not be required to use the <button> as a label, 
> because that forces them to use inferior fallback. The button as a label 
> in a fallback scenario just doesn't seem that common to me.

Yeah I agree that it should be possible to provide a <label> instead of a 
<button>.


> It can be argued, however, that the overloading of <menu> is 
> undesirable, I agree.

It could be argued. I still think it's an opportunity we shouldn't pass 
up, though. We want an element to render menus, and we have "<menu>" with 
convenient fallback characteristic that happens to already be deprecated.


> Thought:
> 
> | <menu>
> |   <li command="cmd_in_head1">Menu Item 1</li>
> |   ...
> | </menu>
> 
> Hmm.

That could work. It's an advanced feature though. (Anything involving 
indirection is going to be harder for users; the more indirection, the 
harder it is, IMHO. This is one reason <font> is easier than CSS.) I'd 
expect use of the command="" attribute to be much rarer than just use of 
<command> itself:

   <menu>
     <command .../>
     <command .../>
     <command .../>
   </menu>

(Falls back to a line break.)


> In that case, could we just require <li> like we do for <ul> and 
> <ol>? Perhaps even replace <menu> with <nl>, making it more like the 
> XHTML 2.0 element?

<nl> doesn't have convenient fallback characteristics.

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