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

[Ian Hickson]

On Sun, 11 Dec 2005, Matthew Raymond wrote:
> >
> > My main problems with the current spec are that it is aethetically 
> > unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is 
> > the whole sibling-<menulabel> thing. It just doesn't feel right. 
> > (Adding a for="" attribute doesn't really save it either, IMHO.)
> 
> I agree that sibling association may not be practical, but an argument 
> against |for| is an argument against all elements that use it, including 
> the HTML 4.01 <label> element.

Indeed.

In the case of <label> it makes slightly more sense since, at least when 
<label> was invented, you never went from the control to the label, only 
the label to the control.

In the case of <output> it makes slightly more sense still, because there 
is no dynamic relation between the <output> and the other control.

In the case of <menulabel>, the presence or absence of the attribute 
directly affects the immediate rendering of the other element, and any 
reference to one element requires examining the other element. It's a much 
closer relationship, and one that happens continually, not just at 
specific points (e.g. on a click).


> Also, you can still use implicit association.

I assume you mean containership?

The problem with

   <menulabel>
     foo
     <menu>...</menu>
   </menulabel>

...is that finding the actual string that corresponds to the title is 
non-trivial. Imagine bidi elements or ruby being sprinkled into it, 
consider the various error-handling cases, ponder what might happen if the 
author sets 'display:block' on the menu explicitly, etc. None of these are 
unsurmountable problems, but the lack of a very simple solution makes it 
less attractive.

There's also the whole conceptual problem (also present with <label>) of 
having the menu be inside its label.


> Well, for a <menu> triggered by a button, you have to have something 
> that acts like a button, so you end up with <menulabel>-like markup in 
> all but the last of these scenarios:
> 
> Sibling Association:
> | <button>Menu Label</button>
> | <menu/>
> 
> Explicit Association (for):
> | <button for="menu1">Menu Label</button>
> | <menu id="menu1"/>
> 
> Explicit Association (popup):
> | <button popup="menu1">Menu Label</button>
> | <menu id="menu1"/>
> 
> Implicit Association:
> | <button>
> |   Menu Label
> |   <menu/>
> | </button>
> 
> XHTML2-Style Approach:
> | <menu>
> |   <label>Menulabel<label>
> |   <li>Item 1</li>
> |   [...]
> |   <li>Item n</li>
> | </menu>

My current thinking goes something like:

   <menu type="commands" label="Menulabel"/>

...where type="commands" means "make a toolbar", and label="Menulabel" 
means "the toolbar has only one button, its value is "Menulabel", and its 
menu is this menu".

I'm not overly joyous about it, but it _is_ simple. :-)

Another option is:

   <button menu="foo"/>
   <menu type="context" id="foo"/>

But as you point out in your mail, this has some of the <menulabel> 
problems (at least when extended to <menu type="commands">-type scenarios 
where you want to make a toolbar of these things).


> The XHTML2 model has significant styling problems, though.

Indeed.

In general, I think having the label be its own element (or attribute) 
without anything inside it other than the label text is the most sensible 
design (semantically), at least when compared to designs that put other 
elements inside the label. But it's not perfect, as you say.

Note that in terms of styling, we shouldn't shy away from saying that CSS 
should be fixed to handle our markup, if CSS sucks. The style should be 
slave to the content, not vice versa.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'