[whatwg] Web Applications 1.0 and Menu Labels

[Matthew Raymond]

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?

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

/me seriously thinks about downloading the Mozilla source code...

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

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

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

> title is a common attribute, so it's already there.

    Oops!

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

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

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