[whatwg] Web Applications 1.0 and Menu Labels

[Ian Hickson]

The spec has changed a lot since this e-mail was sent...

On Mon, 22 Nov 2004, Matthew Raymond wrote:
> Ian Hickson wrote:
> > On Sun, 19 Sep 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?

It's now:

    <menu type="context">
     <menu label="File">
      ...


> > > I like this method of association, and I'd like to see it used with 
> > > <label> as well. I've already seen people using markup like the 
> > > following in HTML4 web pages:
> > > 
> > > <label>Text</label><input type="text" name="text1">
> > > 
> > > So, by associating otherwise unassociated <label> elements such as 
> > > the one above with controls that are immediate siblings, we add 
> > > semantic meaning to many web pages that already use this kind of 
> > > association-by-proximity.
> > 
> > Is this really that common? I haven't seen it at all as far as I can 
> > remember. I don't mind us adding this, but I don't think we want to do 
> > it if the cost in implementations and risk of regressions doesn't get 
> > outweighed by the increased number of pages that would render better.
> 
>    Like I said, I've seen it a few times, although I don't know if it's 
> common. We could just implement sibling association for <menulabel>, 
> although I'd prefer consistency between different types of labels. I'm 
> surprised to here you say that this may be difficult to implement, 
> though. I would not have guessed it would be.

I haven't done this, since I haven't heard any other requests for it.


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

I think the current markup is even neater.


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

I've removed the bit you disliked here.


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

I've simplified it dramatically now.


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

I haven't added anything to make menus have icons or be hidden at this 
point. (Well, there's the global hidden="", which I guess I should hook 
in, but I haven't yet done that either.)


> > >   |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 Thought: Unlike the other two attributes, one could make an 
> argument for moving this to <menu>. The same is not true for |hidden|, 
> though.

I haven't added this either, but I'm sure we'll add it eventually when we 
have a better idea of what uses of this look like.


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

Just make the default command the default, and all else should follow.

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