[whatwg] Menus, fallback, and backwards compatibility: ideas wanted

Matthew Raymond mattraymond at earthlink.net
Sat Dec 10 23:55:31 PST 2005


Ian Hickson wrote:
> On Sun, 4 Dec 2005, Matthew Raymond wrote:
> My main problems with the current spec are that it is aethetically 
> unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is the 
> whole sibling-<menulabel> thing. It just doesn't feel right. (Adding a 
> for="" attribute doesn't really save it either, IMHO.)

   I agree that sibling association may not be practical, but an
argument against |for| is an argument against all elements that use it,
including  the HTML 4.01 <label> element. Also, you can still use
implicit association.

> It just feels like there are too many ways that it could go wrong -- e.g. 
> the sibling isn't there, or whatever.

   Yeah, I prefer to use |for| anyways, because it makes the association
 obvious.

> BTW the goal of reducing the markup isn't to reduce the bandwidth or the 
> size of the document or whatever. Bandwidth is cheap. Disk is cheap. The 
> idea is to make the whole thing look simpler and cleaner to the author, 
> and to make it easier to type.

   Well, for a <menu> triggered by a button, you have to have something
that acts like a button, so you end up with <menulabel>-like markup in
all but the last of these scenarios:

Sibling Association:
| <button>Menu Label</button>
| <menu/>

Explicit Association (for):
| <button for="menu1">Menu Label</button>
| <menu id="menu1"/>

Explicit Association (popup):
| <button popup="menu1">Menu Label</button>
| <menu id="menu1"/>

Implicit Association:
| <button>
|   Menu Label
|   <menu/>
| </button>

XHTML2-Style Approach:
| <menu>
|   <label>Menulabel<label>
|   <li>Item 1</li>
|   [...]
|   <li>Item n</li>
| </menu>

   The XHTML2 model has significant styling problems, though. See my
posts from the www-style mailing list:

http://lists.w3.org/Archives/Public/www-style/2005Oct/0202
http://lists.w3.org/Archives/Public/www-style/2005Oct/0206

   As a result, I think menu labeling based on an element that has the
implicit and explicit association of <label> is still the best approach.
Now with <li>, we can use implicit association:

| <menu>
|   <li>
|     Submenu Label
|     <menu/>
|   </li>
| </menu>

   However, that doesn't solve the problem of a menu that is NOT within
a menu, like one that's triggered by pressing a button. In that
situation, you either have a <menulabel> element or give another element
 <menulabel>-like semantics (which is what we're already doing in the
above example).

   Therefore, I think the best approach is to simply have a <menulabel>
element that handles all submenus and popup-type menus and deal with the
fact that we'll have an extra element in our markup...

| <menu>
|   <li><menulabel>
|     Submenu Label
|     <menu type="popup"/>
|   </menulabel></li>
| </menu>

| <menulabel>
|   Submenu Label
|   <menu type="popup"/>
| </menulabel>




More information about the whatwg mailing list