[whatwg] [WA1] menus

[Matthew Raymond]

Laurens Holst wrote:
> Ian Hickson wrote:
>>> #  <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>
>>>
[Snip!]
>> 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.
> 
> For both semantics and user interface behaviour. Note by the way that a
> <label> tag already exists so I see no need to create a new one.

    Yeah, that way when we need use attributes like |disable| and 
|hide|, we can put them on an element that won't use them in any other 
circumstance, while at the same time overloading existing HTML 4.01 
markup with additional semantic meaning it didn't originally have.

> I think neither option suggested above is good. Just take a look at how
> <label (for="")> is used in HTML and copy that. It is a sensible method.
> If you click on the label, if there is an appropriate element (in this
> case, menu) inside, it will be selected. If you place the menu outside
> the label, the for="" will link it to the menu's ID and all will be well.

    Here's something that I meant to post, but apparently didn't...

Addition to Web Forms 2.0 section "2.3. Changes to existing controls":

"The presentation of a label should match that of the operating system 
unless overridden by styling. For example, if selecting a control causes 
the label to be rendered with a dashed border in the operating system, 
that should be the default presentation in the user agent.

"A <label> element should be able to associate with an immediate sibling 
control element ("sibling association"), so long as no other association 
exists. The <label> element should first attempt to associate with the 
next sibling, then the previous sibling. If no immediate sibling control 
exists, the <label> element will be unassociated.

"An unassociated <label> element has no semantic meaning."

    So you see, my idea is that <menulabel> would simply use the methods 
of association that <label> uses, as of my modified WF2. The <label> 
element is already frequently used without an association. The above 
change to the WF2 spec would make all that markup valid and actually 
make it functional on WF2 compliant browsers. (It's really annoying to 
go to a page where they don't associate the labels with their 
corresponding radio buttons in particular. Sibling association would be 
a huge benefit  when viewing most of those sites.)

> I find the 'define as being labelled by previous element' a rather
> quirky definition, and certainly inconsistent.

    Me too. See my definition above.