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

Ian Hickson ian at hixie.ch
Tue Dec 6 14:18:26 PST 2005


On Tue, 29 Nov 2005, Matthew Raymond wrote:
>>>>
>>>> <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...
> 
> If we must exclude the use of actual menu bars

It wasn't the menubar element I had a particular aversion to, it was 
requiring some sort of container element in general.


> I'd prefer the following: [extraneous markup removed -IH]
> 
> |     <menulabel>
> |       <menu>
> |         <select>
> |           ...
> |         </select>
> |       </menu>
> |       <button type="submit" name="menu">Foo</button>
> |     </menulabel>

That's basically the same thing.



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

IMHO we can't rely on solutions that involve an element being hidden due 
to the presence of an attribute on another element.

[snip other solutions that have this problem]


> | <x>
> |   <menu>
> |     <select>
> |       ...
> |     </select>
> |   </menu>
> |   <button>Foo</button>
> | </x>

This could work. Basically in a new UA if you hit an <x> element you 
render it as a menu button, and you use the contents to determine the 
<menu> and the button label according to some algorithm.

(I've renamed <menulabel> to <x> to remove any mention of what we call new 
elements for now. The structure is what I'm looking at here.)

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



More information about the whatwg mailing list