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

[Lachlan Hunt]

Ian Hickson wrote:
> On Mon, 28 Nov 2005, Lachlan Hunt wrote:
>> How about this, or some variation of:
>>
>> <form ...>
>> <menubar>
>>   <li><button type="submit" for="foo" name="menu">Foo</button>
>>       <select id="foo" name="foo">
>>         ...
>>       </select>
>>   </li>
>>   ...
>> </menubar>
>> </form>
>>
> 
> Interesting idea. I like the non-JS fallback potential. Pity about the 
> <menubar> being necessary to get the <select> to disappear, but I guess 
> we need that...

I originally just used <menu>, which is why the <li>s are there, but I'm 
not sure if its really is necessary.  Couldn't the for attribute used to 
associate the button with the the select, be used to determine how to 
render the controls without the menu/menubar/etc. wrapper?

> It's unfortunate about the button being first, too.

 From an implementation perspective, is there any reason why it couldn't 
work with the order of the button and select elements swapped?  At the 
moment, I thinking it should work if the button and select are just 
immediate siblings of each other in any order, though I'm not sure if it 
should work if there were other content in between.

> I guess we could change that if we say that in the new world in an <li> any 
> <select>s are ignored and just the <button> is looked for... Hmm.

I'm not sure I understand.  Wouldn't that break many existing documents 
which do have select and buttons inside li elements?  What if it were 
done like this:


<label>
   <button for="foo">Foo</button>
   <select id="foo">
     ...
   </select>
</label>

or

<label>
   <select id="foo">
     ...
   </select>
   <button for="foo">Foo</button>
</label>

In these cases, the button is acting as the label for the select menu 
which makes sense semantically and it probably wouldn't require any 
extraneous <menu[bar]> markup.  There is, however, still the extra |for| 
attribute, but I think it (or something similar) is necessary so that we 
don't inadvertently break any existing documents that do have buttons 
and selects together in a label element.

Alternatively, we could ditch the |for| attribute and substitute another 
element for label or, if possible, do as I suggested above and just use 
the |for| attribute to associate them regardless of their 
parent/ancestor elements.

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