[whatwg] Web Applications 1.0 and Menu Labels
mattraymond at earthlink.net
Mon Nov 22 06:26:53 PST 2004
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 when I noticed something. Here's a snipped version
>>of the example:
>> <a href="#file">File</a>
>> <menu id="file">
>>Notice that the <a> element is being used in place of a <menulabel>.
>>This doesn't really make sense because it overloads the semantics of <a>
>>without reason. Consider the above example with <menulabel> added:
>> <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:
> ...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...
>> <menulabel label="File">
>> <command label="New..." onclick="fnew()"/>
>> <command label="Open..." onclick="fopen()"/>
>> <command label="Save" onclick="fsave()" id="save"/>
>> <command label="Save as..." onclick="fsaveas()"/>
> 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
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...
>> <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
> 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.
>> |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
Idle Though: Unlike the other two attributes, one could make an
argument for moving this to <menu>. The same is not true for |hidden|,
>> |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.
More information about the whatwg