[whatwg] Web Applications 1.0 and Menu Labels

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.


> I noticed that <menulabel> in the WA1 spec is associated with the 
> immediate menu item:
> 
> "The semantic of the menulabel element is that it labels its following 
> sibling element, which must be a menu element. [...] A menulabel whose 
> next sibling element is not a menu element is semantically 
> [meaningless]."[3]
> 
> 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.


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


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


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


> [attributes for <menulabel>]
> 
>    |title| - Some programs do have values like this for submenu labels.

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


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


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


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


>    At any rate, I think there's still a lot to work on with the markup 
> for menus.

Yes.

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

Received on Sunday, 21 November 2004 10:26:53 UTC