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

[Ian Hickson]

So... menus.

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

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 
requirements: 

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

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:

    <p>
     <button menu="x">Action...</button>
     <menu id="x"><a href="">...</a> <a href="">...</a></menu>
    </p>

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

    <p>
     <button>
      Action...
      <menu><a href="">...</a> <a href="">...</a></menu>
     </button>
    </p>

No legacy compatibility story.

    <p>
     <button>
      Action...
      <select onchange="..."><option value="..."><option value="..."></select>
     </button>
    </p>

Breaks in modern browsers (especially Safari, which puts the <select> 
outside the button).

   <p>
    <menubar>
     <label for="x"> Action... </label>
     <select id="x" onchange="...">
      ...
     </select>
    </menubar>
   </p>

Good back-compat story, but far too heavy on the markup. Suboptimal 
element name <menubar>, with no obvious alternatives.

   <p>
    <menubar>
     <label>
      Action...
      <select onchange="...">
       ...
      </select>
     </label>
    </menubar>
   </p>

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

  <menu label="Action">
   Action...
   <select onchange="...">
    ...
   </select>
  </menu>

(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.   `._.-(,_..'--(,_..'`-.;.'