[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
ian at hixie.ch
Sun Nov 27 00:00:56 PST 2005
I've spent the last few days carefully examining all the posts on context
menus that have been sent to the list (mainly Matthew Raymond's excellent
proposals), as well as looking at the current draft in the spec, and real-
world markup on major sites.
There are four main use cases for menus on the Web, as far as I can tell
(please let me know if you can think of another case):
1. Providing a menu bar for the entire window (or application, on Mac), so
that the application can be a native-like application. This, IMHO, is
out of scope for HTML5 and should maybe be revisited in HTML6 by
whoever does the work on taking HTML out of the browser, if that ever
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.
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.
4. Replacing ad-hoc DHTML context menus with something more accessible,
that doesn't necessarily replace the UA's own context menus.
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.
So to simplify, the use cases we want to cover are context menus,
discoverable context menus, and sets of discoverable context menus.
Our requirements for how to design the markup for this are the usual
A. It has to have graceful fallback in older UAs (ideally, in this case,
the ability to have fully functional fallback no worse than today's).
B. It has to have a sane migration path from the old-style markup to the
new kind of markup.
C. It has to have no requirements that would cause old pages to have
different behaviour in UAs that support HTML5 compared to those that
D. It has to be reasonably clean markup, easy to understand and author.
E. It has to be reasonably easy to implement.
D and E imply that we should avoid overloading semantics (e.g. we should
avoid reusing an existing element that already has baggage, like taking
<select> and saying "if it has this magical attribute, it's actually a
menu button" or some such).
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.
I think the current core menu stuff (<command>, how to build menus, etc)
is reasonable. The big problem with the current proposal is how to do the
fallback in a sane way.
I'd really like to be able to fall back on the <select onchange=""> abuse,
since it is easy to define how to make a menu from that, but I don't want
to just put an attribute on the <select> element to change its behaviour
-- it's got to still be a <select>, just one that happens to not be
visible in new UAs, with its semantics wrapped around another level of
semantics. The problem is trying to come up with a neat way of doing this
while still hitting all the requirements above.
Take this markup from today:
<p>Action: <select onchange="..."><option>...<option>...</select></p>
Here are some possible ways we could do this:
<menu id="x"><a href="">...</a> <a href="">...</a></menu>
(<menu id> would cause the <menu> to hide in new UAs.) This sucks for two
reasons: forced indirection, and the fallback story is poora at best.
<menu><a href="">...</a> <a href="">...</a></menu>
No legacy compatibility story.
<select onchange="..."><option value="..."><option value="..."></select>
Breaks in modern browsers (especially Safari, which puts the <select>
outside the button).
<label for="x"> Action... </label>
<select id="x" onchange="...">
Good back-compat story, but far too heavy on the markup. Suboptimal
element name <menubar>, with no obvious alternatives.
A mess for implementors -- no good way to render that as a button in a
CSS world (or even in an XBL2 world, actually). Also quite misleading
(Where the label attr on <menu> would make the element into a menu button)
Duplication of the label, bad for i18n (can't set a different language on
part of the attribute -- though I'm not convinced that's a blocker
problem, to be honest), makes the <input type> mistake of having an
element's behaviour change radically based on an attribute (bad for
authors and implementors).
Anybody got any better ideas?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg