[whatwg] [WA1] menus

[Ian Hickson]

On Sat, 13 Nov 2004, Matthew Raymond wrote:
> > >
> > > Maybe the first example[1] can changed. Now MENU is the sibling of 
> > > the A element and that is a strange construct since A is an inline 
> > > element and MENU a block level element. Perhaps MENULABEL[2] can be 
> > > used to wrap the A element in. From:
> > > 
> > > #  <menubar>
> > > #   <li>
> > > #    <a href="#file">File</a>
> > > #    <menu id="file">
> > > #     <li><button type="button" onclick="fnew()">New...</button></li>
> > > 
> > > To:
> > > 
> > >  <menubar>
> > >   <li>
> > >    <menulabel><a href="#file">File</a></menulabel>
> > >    <menu id="file">
> > >     <li><button type="button" onclick="fnew()">New...</button></li>
> > > 
> > > This would make it a lot better, from a structural point of view. It 
> > > would also remain backwards compatible.
> > 
> > What's the (practical) difference? So long as we define the menu as 
> > being labelled by the previous element, the two cases above are 
> > equivalent.
> 
> There are several reasons:
> 
> 1) The <a> element is a logical choice for non-menu items in the 
> menubar, since it can already be used in a way similar to command in 
> <menu> elements:
> 
> | <menubar>
> |  <li>
> |   <menulabel><a href="#file">File</a></menulabel>
> |   <menu id="file">
> |    <li><button type="button" onclick="fnew()">New...</button></li>
> |    <li><button type="button" onclick="fsave()">Save...</button></li>
> |    <li><button type="button" onclick="fexit()">Exit</button></li>
> |   </menu>
> |  </li>
> |  <li><a href="help.htm" target="_blank">Help</a></li>
> | </menubar>
> 
> 2) A HTML 4.01 webmaster looking at markup like Anne's first example 
> cannot immediately tell that the <a> element is a menu label without 
> having consulted the WA1 spec first. While they may be able to logically 
> deduce that it's a menu label after examining the markup, it's clear the 
> use of <a> alone impairs readability.
> 
> 3) There's absolutely no need for overloading the <a> element, because 
> as the second example shows, you can just wrap the hyperlink in the 
> existing <menulabel> element. I think we should on principle avoid 
> semantically overloading markup as much as possible. (The <menu> element 
> is an exception, because it's depreciated in HTML 4.01 and because its 
> name is an obvious impediment to menu-related markup.)
> 
> 4) Menu labels naturally don't contain hyperlinks, so if we are to keep 
> <menulabel> as part of the specification then <menulabel> should ignore 
> any child <a> elements. As a result, Anne's second example becomes valid 
> anyway, so why implement a second method of labeling menus?
> 
> 5) Unless you plan to add attributes like |hide| and |disabled| to the 
> <a> element, we still need <menulabel>, especially for submenus.
> 
> 6) It creates the possibility that some webmasters may just not use 
> <menulabel> at all when they create their first menus. Therefore, if 
> they choose to upgrade their web pages to use some of the more advanced 
> menu features mentioned above, they'll have to structurally change their 
> markup prior to using any of the aforementioned attributes.

The spec now uses a "label" attribute on <menu> elements to handle this. 
Hopefully this addresses these issues.

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