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

[Lachlan Hunt]

Matthew Raymond wrote:
> Lachlan Hunt wrote:
> 
>    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.

Good point.  Agreed, we need an explicit label, but using the button 
text is ok if the label is not present (if that's possible for 
implementations to do).

>>>| <menulabel for="menu1">Label Text</menulabel>
>>>| <menu id="menu1">
>>>|   <select/>
>>>|   <button/>
>>>| </menu>
>>
>>We already have <label> for form controls, I don't think we need a new 
>>element for that especially when it's basically still associating a 
>>label with a form control.  I also think you're overloading the use of 
>>the menu element too.
> 
>    The <menulabel> is associated with a menu, so unless you have a 
> opposition to that, I don't see your point. It can be argued, however, 
> that the overloading of <menu> is undesirable, I agree.

My point is that this command menu is basically made up of a label, a 
select control and a button, and that we already have a <label> element 
for associating with select elements.  Therefore, we don't need to use 
another type of label element for that.  <menulabel> is fine for 
navigational menus.

>>3. <cmd>
>>     <label>Jump to <select/></label>
>>     <button>Go</button>
>>   </cmd>
> 
>    This is fine.
> 
>>4. <cmd>
>>     <label for="jump">Jump to</label>
>>     <select id="jump>/>
>>     <button>Go</button>
>>   </cmd>
> 
>    Same here.

They're the ones I preferred too.

>>>Not menus, mind you, but menus within menus. If not, then we could 
>>>drop <cmd> from the list of possible children for <menu> while 
>>>keeping the element itself.
>>
>>I don't understand your logic behind this.
> 
> 
>    If there isn't a use case for having <cmd> as a direct child of 
> <menu>, why allow it to be the direct child of <menu>??? Furthermore, if 
> <cmd> supports multiple submenu levels, you can just use it for the 
> whole menu structure rather than a submenu. (Or, <cmd> could be require 
> to be a child of <li>. See below.)

I thought there was a use case, where cmds as direct children of a menu 
element would form the menu bar, and the select/button elements would 
form each individual menu:

<menu>
   <cmd>
     <label>File <select name="file"/></label>
     <button name="menu" value="file">Go</button>
   </cmd>
   <cmd>
     <label>Edit <select name="edit"/></label>
     <button name="menu" value="edit">Go</button>
   </cmd>
   <cmd>
     <label>View <select name="view"/></label>
     <button name="menu" value="view">Go</button>
   </cmd>
</menu>

That might be rendered like this:
  _____________________
|File  Edit  View     |
|---------|___________|
| New...  |
| Open... |
|_________|

>    Hmm. 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?

That would be an alternative, but <menu><li> is already supported by 
existing UAs.  I wouldn't mind requiring li for content other than cmd, 
since we already use it within ul for menus, and other than reduced 
markup, I see no other benefit in leaving it out.

That would make the content model for menu look somethink like this:

<menu>
    <cmd>          <!-- Menu command item -->
      <label/>     <!-- Label for command menu -->
      <select/>    <!-- The menu items -->
      <button/>
    </cmd>
    <li>           <!-- Menu list item (e.g. navigational list) -->
      <menulabel/> <!-- Label for nav menu -->
      <menu/>      <!-- The menu items -->
    </li>
    <li><a href=""/></li>
</menu>

Requiring an li around <cmd> would just be extra markup for no good reason.

Earlier, Ian Hickson wrote:
> 1. Providing a menu bar for the entire window (or application, on Mac), so 
>    that the application can be a native-like application. This, IMHO, is 
>    out of scope for HTML5 and should maybe be revisited in HTML6 by 
>    whoever does the work on taking HTML out of the browser, if that ever 
>    happens.

I just had a thought that maybe this could be marked up by including the 
<menu> within the <head> element, since the content of the head element 
contains metadata applying to the whole document, and an application 
menu bar applies to the whole application, it makes sense for such a 
menu to be marked up like that.  However, this would only be possible in 
XHTML documents.

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