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

[Lachlan Hunt]

Ian Hickson wrote:
> 2. Replacing ad-hoc DHTML menus with something accessible yet stylable.
>    Sites like kelloggs.com and target.com are great examples of such 
>    menus and their problems today.

I agree with Anne that lists are already the best method of implementing 
these navigational menus.

> 3. Replacing ad-hoc menu buttons, as seen in the folder view of Yahoo! 
>    mail (the "Mark" button, for instance) or of msn Hotmail (the "Put in 
>    Folder" button, for instance), and abuse of the <select> widget to 
>    get similar effects, as seen in GMail (the "More Actions..." dropdown, 
>    for instance) or United Media's comics sites (the "Comics List" 
>    dropdown on, e.g., dilbert.com), with something more accessible.

While I don't agree with the abuse of select elements for navigational 
menus and the spec should not encourage such markup, I somewhat agree 
with their use for command menus such as the hotmail, gmail and yahoo 
examples.  The United Media comic sites seem to be navigational menus 
and are abuse of the select element.

The difference is that navigational menus are just links, but the 
command menus actually perform a function (like "mark as read", "move to 
folder", etc. in various email apps).  For such commands, links are 
inappropriate markup, forms controls/buttons are better.

The only problems I have with their use is:
a) common implementations require the use of javascript to function 
properly, however good sites should provide submit buttons to perform 
the same function without JS enabled.

b) The use of onchange causes significant problems with keyboard 
selection, as the event is typically fired for every change, rather than 
just the user's final selection.  This, however, is probably more of an 
implementation issue.  e.g. if the UA expaned the menu when the user 
pressed the down arrow and didn't finalise the selection until the user 
pressed enter or tabbed away from the control, that might solve this 
problem.

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

> If we ignore 1 as being out of scepe, then we see that 2, 3, and 4 are 
> really just variations on the same theme. For example, menu buttons are, 
> in practice, just attempts to make context menus more discoverable; the 
> only difference is how you invoke them. Furthermore, most DHTML menus 
> consist of just a lot of menu buttons side by side.

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

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

> Anybody got any better ideas?

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)
Values submitted as:

?menu=Foo&foo=value&bar=value

The server can use the name of the submitted button to determine which 
menu item matters.

Or, JavaScript can handle the onchange event in the select element 
instead of submitting the form.

-- WA1 UAs --

* Button expands menu, and the form is submitted upon selection OR 
javascript handles it and cancels the form submission.
* Should also work with <input type="submit">, which is supported better 
by IE.

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