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

[Matthew Raymond]

Lachlan Hunt wrote:
> Matthew Raymond wrote:
>>Lachlan Hunt wrote:
>>>AIUI, the difference between them can be illustrated as follows:
>>>
>>><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>.

>> You would only use the button for submission. Here's a
>>stripped down version of what Ian has on his weblog:
>>
>>| <form action="./" method="get">
>>|   <p>
>>|     <label>
>>|       Jump to
>>|       <select name="start"/>
>>|     </label>
>>|     <input name="order" value="-1" type="hidden">
>>|     <input name="count" value="5" type="hidden">
>>|     <input value="Go" type="submit">
>>|   </p>
>>| </form>
>>
>>   Also, as you point out, the <input> element could be used instead. So
>>you'd need either a <label> or child text, as you see Ian using above.
> 
> Why?  <input type="submit"> is still a button, what difference does it 
> make from the button element?

   It doesn't matter if it's a <button> or an <input type="submit">,
because neither have label semantics for anything external to themselves.

> But, if you really don't like overloading the use of the button as the 
> menu label as well, then I guess we could add a label, but I think just 
> using the button itself has the advantage of less markup and if the 
> button isn't required to get the menu, authors won't bother including 
> it, which reduces accessibility.

   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.

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

> Do you like the structure of any of these alternatives? (with the actual 
> element names still up for discussion)
> 
> 1. <cmd>
>      <button>Jump to</button>
>      <select/>
>    </cmd>

   Works, though not ideal.

> 2. <cmd>
>      Jump to <select/>
>      <button>Go</button>
>    </cmd>

   This works. A <label> would provide better fallback semantics, though.

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

> 5. <cmd>
>      <label>Jump to <select/> <button>Go</button></label>
>    </cmd>

   No. This has the same implicit association problems we spoke of
earlier, and it's unnecessary, since <cmd> establishes any relationships
between the elements that we need.

> 6. <label>
>      <cmd>Jump to <select/> <button>Go</button></cmd>
>    </label>

   If <cmd> is not a form control, they you're semantically overloading
<label>. You're also using <label> in a way that's similar to
<menulabel>, which could confuse web authors. If we merge the two, we
still have the problem of <label> calling menus that aren't technically
form controls, thus overloading <label> in a clearly semantic way.

> 7. <label for="jump">Jump to</label>
>    <cmd id="jump">
>      <select/>
>      <button>Go</button>
>    </cmd>

   Ditto here as well.

>>   Hmm... Is there really a use case where we'd be using <select> 
>>elements for submenus?
> 
> Not that I can think of, but select elements could have submenus using 
> the optgroup element, as currently described in the spec.

   That's true, and they have multiple levels if you allow <optgroup>
nesting.

>>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.)

>>| <menu>
>>|   ...
>>|   <command/>
>>| </menu>
> 
> Why does <command> need to be a child of menu at all?  It's really more 
> of an abstraction, rather than a physical control for the user to use. 
> Wouldn't it be better for them to be declared within the <head> or early 
> within the <body> and then referenced by other controls as needed?

   Actually, I was thinking the same thing. Hence my comments about it
looking like the XUL element, which I believe to be similar. If you can
create some good examples and/or use cases for this, I'll probably back
you on that one.

   Thought:

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

   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?