[whatwg] Web Applications 1.0 and Menu Labels

Since this e-mail was written, the menu section changed quite a bit.

On Mon, 22 Nov 2004, Matthew Raymond wrote:
> > >
> > > I was looking at the example in the "2.1. Tutorial" section of Web 
> > > Applications 1.0[1] when I noticed something. Here's a snipped 
> > > version of the example:
> > > 
> > > <menubar>
> > > <li>
> > >  <a href="#file">File</a>
> > >  <menu id="file">
> > > 
> > > Notice that the <a> element is being used in place of a 
> > > <menulabel>[2]. This doesn't really make sense because it overloads 
> > > the semantics of <a> without reason. Consider the above example with 
> > > <menulabel> added:
> > > 
> > > <menubar>
> > > <li>
> > >  <menulabel><a href="#file">File</a></menulabel>
> > >  <menu id="file">
> > > 
> > > The above example degrades in exactly the same way. The difference 
> > > is that only <menulabel> is used to label menus. As a result, 
> > > webmasters don't have to memorize an additional rule about the use 
> > > of <a>. Furthermore, since there's no apparent reason to have a 
> > > hyperlink inside a menu label, the UAs would need to ignore <a> 
> > > elements inside <menulabel> elements anyways.
> > 
> > According to the current definitions, it could just as easily have 
> > been:
> > 
> >    <menubar>
> >     <li>
> >      <p>File</p>
> >      <menu>
> > 
> > ...and it would mean pretty much the same thing. The only reason to 
> > use a link is that that's what people are using now, and I wanted the 
> > example to have the least changes required from existing markup. (That 
> > is, going from existing markup to this markup should be easy.)
> > 
> > The semantics here are coming from the fact that the <li> element has 
> > a <menu> child; the label is simply whatever the previous sibling of 
> > the <menu> is.
>
> There's two problems with this. First is that you're totally reversing 
> the direction of label association by making the object of the label 
> associate to the label rather than the other way around that exists with 
> <label>. The second problem is readability. I have to scan the document 
> for a menu first, then backtrack to figure out where the menu label is. 
> With the <menulabel> element, people can simply scan the document for 
> "menulabel".
> 
> Also, the user could easily achieve the same effect for legacy UAs using 
> "<p><menulabel>File</menulabel></p>", so what's the point other than to 
> save a bit of typing?

This is now all gone; submenus are just done with <menu label="">.


> > > I'd also like to see <menulabel> use the association methods 
> > > available with <label>, like implicit association...
> > > 
> > > <menubar id="appmenu">
> > > <menulabel label="File">
> > >  <menu>
> > >   <command label="New..." onclick="fnew()"/>
> > >   <command label="Open..." onclick="fopen()"/>
> > >   <command label="Save" onclick="fsave()" id="save"/>
> > >   <command label="Save as..." onclick="fsaveas()"/>
> > >  </menu>
> > > </menulabel>
> > > </menubar>
> > 
> > This would unfortunately make implementing <menulabel> quite a lot 
> > harder for little net gain to the author. I understand that it would 
> > be nice and symmetric, but in this case it doesn't seem like there 
> > really are many benefits.
>
> You may be right with regards to difficulty of implementation, but it 
> makes it significantly more readable when doing submenus.

The latest spec on this makes this hopefully a lot easier.


> > > ...Or using the |for| attribute...
> > > 
> > > <menubar id="appmenu">
> > > <menulabel label="File" for="file"/>
> > > [...]
> > > <menu id="file">
> > 
> > You can do this with <a> in a more backwards-compatible manner.
> 
> No you can't. See the |label| attribute? Even setting that aside, you 
> could always do this:
> 
> | <menubar id="appmenu">
> | <menulabel for="file"/><a href="#file">File</a></menulabel>
> | [...]
> | <menu id="file">
> 
> And let's not forget the fact that I oppose the use of <a> elements to 
> activate menus, as you currently have specified in WA1. This is both 
> description of behavior (which is what did in <label>'s focus passing) 
> and an overloading of semantic meaning for the element.
> 
> (Having <a> elements as _items_ in a menu is different, because in that 
> case they are acting as hyperlinks, and therefore behave as one might 
> expect them to behave in that context.)

The spec now only has <a> for hyperlinks.


> > > <MENULABEL>, <COMMAND> ATTRIBUTES AND SUBMENUS:
> > > 
> > > There are surprisingly few examples in the WA1 specification 
> > > regarding submenus.
> > 
> > That's mostly becuase I haven't yet worked out how to make section 6.3 
> > (the <menu> and <menubar> elements) work properly. At the moment 
> > they're the worst of several worlds; poor styling, poor native-ness, 
> > etc.
> 
> Please elaborate. I thought my examples where quite elegant. (Is there 
> an operating system or environment that prohibits submenus?)

Right now the spec supports full native, so that should be a non-issue 
now. We can add custom rendering stuff in the rendering section later 
should it be deemed necessary, of course.


> > >   |icon| - I'm not sure if this is necessary, but might be nice.
> > >   |hide| - You may not always want a submenu label visible.
> > 
> > Good point. I've noted that submenus need those. It might actually be 
> > best to put these on the <menu> element, though; they are properties 
> > of the menu, not the label.
> 
> Let me get this straight. The attribute |icon| controls the icon in the 
> menu label, and |hide| hides the menu label, thus preventing access to 
> its submenu, yet you don't feel they are properties of the menu label? I 
> think you are projecting the flaws with your <a> element scheme onto the 
> <menulabel> element.

This is all academic now that we don't have the indirection anymore.


> > >   |disabled| - You may not always want a submenu label enabled.
> > 
> > It's my understanding that disabling a menu is considered poor form, 
> > and that it is better to disable all the children. (mpt?)
> 
> Oh, that would be fun, adding |disabled| to every item in the submenu. 
> I'd just love typing "disabled='true'" twenty times.
> 
> The UA can just show the submenu if disabling the submenu label is a 
> problem, but don't force users to disable individual items when the want 
> the whole menu or short change operating systems that may support such 
> disabling.
> 
> Idle Though: Unlike the other two attributes, one could make an argument 
> for moving this to <menu>. The same is not true for |hidden|, though.

We don't have the command="" attribute defined yet, but with that, you 
would indeed want to disable the controls individually instead of doing 
it at the menu level. It's pretty simply to do anyway, in practice.


> > > |default| - If the menu is being used for navigation, you may want 
> > > the submenu label to be shown as a default if the page you are 
> > > currently on is within the submenu (and also set as the default). I 
> > > actually worked on an in-house application where my supervisor 
> > > specifically asked for this kind of feature.
> > 
> > It would be up to the UA to make the submenu default if it contained a 
> > default item, assuming the platform guidelines said to do this.
> 
> True. The platform may not even support default items, but I fail to see 
> why we can't put it in just in case. I've personally worked on a project 
> that used default values on submenu labels.

I don't really understand what that would mean. "default" is a concept 
that applies to a single command. (It would be nice if we could make it an 
implicit thing, actually. I don't really see how though.)

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

Received on Monday, 6 August 2007 14:20:05 UTC