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

On Tue, 13 Dec 2005, Matthew Raymond wrote:
> > 
> > The problem with
> > 
> >    <menulabel>
> >      foo
> >      <menu>...</menu>
> >    </menulabel>
> > 
> > ...is that finding the actual string that corresponds to the title is 
> > non-trivial.
> 
> I don't see how it's any more difficult than dealing with a <label>.

Simple. You don't have to do it for <label>. :-)

User agents don't analyse <label> elements to determine what the label is, 
they just render everything using CSS.

For menus, we want to be able to get a string out of whatever represents 
the label so that we can pass them to the OS.


> > There's also the whole conceptual problem (also present with <label>) 
> > of having the menu be inside its label.
> 
> Well, in most user interfaces, clicking on the label brings up the menu, 
> so there's sort of a child relationship already. It does introduce a few 
> minor inheritance issues in CSS, but those seem rather trivial to me. To 
> be honest, I don't see this as being much of an issue.

I meant the semantic problem. <x> <y/> </x> implies that <y> is part of 
<x> -- but the control or menu is not part of its label, conceptually.


> >    <menu type="commands" label="Menulabel"/>
> 
> I don't think this is going to fly for menu buttons and the like. Web 
> authors are going to want to style the menu buttons.

Well, the above is no less stylable than:

   <input type="menu" value="Menulabel"/>

...or whatever. I mean, it's one element. No?


> As for toolbars or similar menus, just use |title|.

The "title" attribute is for the tooltip/hint, not the label.


> >    <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).
> 
>    Actually, it's no different from this:
> 
> | <menulabel for="foo"/>
> | <menu type="context" id="foo"/>

Yes. (It's also similar to some of your suggested <button/><menu/> 
examples, for that matter.)


> You've simply changed the element and attribute names. Using <button> 
> may have fallback advantages, though. Also, I'm concerned that the name 
> "menu" for the attribute many not be specific enough, especially if we 
> allow both context menus and popup menus.

True.


> > 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.
> 
> I suppose, but there's still the matter of the time it takes to 
> implement the spec, especially if we create dependencies on CSS, so we 
> can't ignore it entirely.

Sure.


> Also, I like the idea of decoupling the label from the target element. 
> It allows for multiple labels to target the same element.

Yeah, this is something that I'd like to support too. I'm not sure the 
right concept to decouple is "label", though. Showing the menu could also 
be considered a command of kinds. I'm still vague about this.

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

Received on Tuesday, 13 December 2005 17:19:59 UTC