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/
