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

[Ian Hickson]

On Mon, 28 Nov 2005, Lachlan Hunt wrote:
> 
> > 4. Replacing ad-hoc DHTML context menus with something more accessible,
> >    that doesn't necessarily replace the UA's own context menus.
> 
> If the spec were to address this kind of menu, then it must not 
> completely override the UAs own context menu.  However, since these 
> aren't really discoverable until the user right clicks to do something, 
> only to discover their expected menu has been replaced (or at least 
> modified) it may be more of an annoyance than a useful feature.  Of 
> course, that doesn't stop authors attempting them already using JS.

Right; one of the major advantages of doing this semantically is that the 
UA can merge the author's context menu with the UA's.


> I disagree, I see use cases 2 and 3 as completely separate (as described 
> above), not just variations of each other.

Sure, they have different semantics. But they are still menus. They would 
have different ideal markup, and different non-JS fallback (e.g. <a> vs 
<button> as the tags describing the commands) but they're still menus.


> > Matthew has pretty much convinced me that trying to grandfather the 
> > current DHTML menu syntaxes into the new markup is not worth it, so we 
> > can ignore that requirement.
> 
> Could you please explain what "grandfather the current DHTML menu 
> syntaxes into the new markup" means or references to a few of Matthew's 
> specific posts describing the issue?

See, e.g.,
   http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-November/002411.html
   http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-October/004890.html
...and other posts on those threads.


> 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>
>   <li><button type="submit" for="bar" name="menu">Bar</button>
>       <select id="bar" name="bar">
>         ...
>       </select>
>   </li>
> </menubar>
> </form>
> 
> -- Behaviour in Current UAs --
> 
> * User selects item from select menu, button submits it.
> * Con: Submit button occurs before form control, though they typically occur
> after, which may be bad for usability in current/older UAs (could be changed
> with CSS, I guess).
> * Very good support for UAs without JS (assuming the server side processing
> has been implemented to support it)

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... It's unfortunate about the button being first, too. 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.

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