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

Thu Dec 1 04:03:25 PST 2005

Matthew Raymond wrote:
> Lachlan Hunt wrote:
>> No, command in the current spec represents an abstract form control for 
>> sharing features among several real form controls.
> 
>    The <command> element is most certainly not a form control, since it
> can't be submitted

I know that, I said *abstract* form control, though perhaps I should 
have omitted the word "form".

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

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

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.

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

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>

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

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

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

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

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

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

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

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

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

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