[whatwg] [WA1] menus
ian at hixie.ch
Mon Aug 6 11:07:10 PDT 2007
On Sat, 13 Nov 2004, Matthew Raymond wrote:
> > >
> > > Maybe the first example 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 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg