[whatwg] [WA1] menus

[Matthew Raymond]

Ian Hickson wrote:
> On Sun, 29 Aug 2004, Anne van Kesteren 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.


    Also see the following message I posted previously:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-September/002251.html