[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
lachlan.hunt at lachy.id.au
Sun Nov 27 19:21:13 PST 2005
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:
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
> 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:
<li><button type="submit" for="foo" name="menu">Foo</button>
<select id="foo" name="foo">
<li><button type="submit" for="bar" name="menu">Bar</button>
<select id="bar" name="bar">
-- 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:
The server can use the name of the submitted button to determine which
menu item matters.
instead of submitting the form.
-- WA1 UAs --
* Button expands menu, and the form is submitted upon selection OR
* Should also work with <input type="submit">, which is supported better
More information about the whatwg