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

Wed Dec 7 16:00:26 PST 2005

On Wed, 7 Dec 2005, Matthew Raymond wrote:
> > 
> >    <menu>
> >      <command .../>
> >      <command .../>
> >      <command .../>
> >    </menu>
> 
>    Doesn't the following do the same?
> 
> <menu>
>   <option label="1"/>
>   <option label="2"/>
>   <option label="3"/>
> </menu>

It does if we say it does.

Why would we do this? I don't really want to add a lot of new attributes 
to <option>; it would overload <option> and that element is already having 
plenty enough fun with <select>, <optgroup>, <datalist>, form submission, 
"am i control or am i not" schizophrenia, etc.

> We can just use <option> elements instead of <command> when we need to 
> hide menus. If we're going to support <select> elements as menu fallback 
> markup, <menu> will have to support <option> elements anyways. This 
> frees up <command> to be used specifically in the <head>.

I don't see any reason why <command> can't be used in the head anyway.

Basically I think the way that <menu> will have to support <option> is 
separate and distinct from the way that it will have to support other 
commands. I don't expect <option> to support everything that <command> 
might. Do you disagree?

> Sort of. I'm leaning towards having all elements but <option> nested
> in an <li> element, though.

Yeah, I'm just worried that people are going to want more flexible 
fallback than a bulleted list though (notwithstanding the fact that you 
can use CSS to change the presentation).

> It just seems to have better semantics, and it also allows you to use 
> multiple elements to build a menu item, like having an <img>, a <input 
> type="checkbox"> and a <label> in the same <li> to create a menu item 
> with a checkbox and an icon.

Oh I certainly agree that we want to allow <li>.

> > Not quite sure how to get the label for nested <menu> elements yet.
> 
> I fail to see what's wrong with using the activation of <menulabel> to 
> display menus.

I dunno, it's just ugly. I wasn't really happy with it when I first put it 
in the spec and the more I look at it the less I like it. (See also 
earlier mail about this.)

> Part of the benefit of [menulabel] is the ability to call menus that are 
> outside the <menubar>:

Yes, we want to keep that functionality. There might be neater ways to do 
this than <menulabel for="">, though. Maybe even <menu def=""/> or 
something.

> For toolbars, something similar to <menubar> that takes <button> or 
> <menulabel> children seems in order. I prefer doing this as opposed to 
> <menu type="menutype">, especially since <input type="[type]"> has 
> receive some resistance.

So the main problem with <input type=""> is that one element is used for 
things that need to be implemented in fundamentally different ways.

The proposal with <menu> is not as bad. Specifically, we have these cases:

 * <menu> is dumb (can just be styled by CSS).

 * <menu> is hidden.

 * <menu> is replaced by a toolbar.

In addition, any <menu> can be used to generate a native menu. This isn't 
something relevant to <menu> itself, though -- much like the fact that you 
can generate an outline from <h1>s, etc, is not really that relevant to 
the <h1> elements themselves.

> It also creates specific elements they have to support rather than 
> attribute values, which makes it harder for vendors to falsely claim 
> support.

The solution to that problem is test suites, not compromises in language 
design, IMHO.

> I think it also increases visibility.

Not sure what you mean here.

> Thought: Is the distinction between a menubar and a toolbar entirely 
> presentational? Use one element? <commandbar>?

I don't think there is any difference at all between <menubar> and 
<toolbar>, really, hence wanting to just use <menu>.

> Not sure I like the whole thing about the user agent guessing it's a 
> menu based on if it has a label or is connected to a context menu 
> reference. Might just be able to fix that by requiring the |label| 
> attribute. Then again, it seems like it's doing what could be done with 
> the |title| attribute.

Agreed.

> Perhaps an attribute |type| with the possible values "menu" and "list", 
> where "list" is the default.

Yeah.

> Then again, toolbars often have separators, so maybe they're a type of 
> list anyways and require <li>-type markup, thus making <menu type> more 
> appropriate. Hmm...

<hr> is our separator element. Not sure what it stands for exactly. "Here 
is a separatoR", maybe. *cough*

> Above, the type "menu" is assumed to be a sort of context menu activated 
> either by a true context menu feature or by a <menulabel>. Then again, 
> <commandbar>-type elements are flat, and while they may have 
> groupings/separators (for toolbars, at least), they don't have 
> multilevel groupings.

They kind of do, in some contexts, e.g. drop-down buttons.

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