[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