W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2004

[whatwg] [WA1] menus

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 10 Dec 2004 09:40:01 -0500
Message-ID: <41B9B541.7030107@earthlink.net>
Ian Hickson wrote:
> On Sat, 13 Nov 2004, Matthew Raymond wrote:
>>"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.
> 
> I'm reluctant to make <label> any harder to implement than it already is. 
> Also, one problem with that definition is it starts getting quite 
> confusing when you have cases like:
> 
>    ...
>    <input type="checkbox">
>    <label> ... </label>
>    <input type="checkbox">
>    <label> ... </label>
>    <input type="checkbox">
>    <label> ... </label>
>    <input type="checkbox">
>    ...

    This is potentially fixable, but only if we assume certain OS 
conventions, so point taken.

> Sibling association is something I'd rather avoid in general -- I'm not 
> particularly fond of it when it comes to the Web Apps menu stuff either. 
> (The more I think about it, the less I like the current <menubar> stuff.)

    I'd very much appreciate it if you'd post your concerns about the 
current draft menu markup in a new thread so that we can address it 
separately from the label issue, and in more detail.

>>"An unassociated <label> element has no semantic meaning."
> 
> It's a label. It just doesn't label anything. I don't see any reason to 
> say that it stops being a label just because it isn't labelling anything.

    I'm going to have to disagree with you on this one. A <label> could, 
in theory, have a different default styling depending on what kind of 
control it's associated with. For instance, under Windows Xeroderma 
Pigmentosum, a radio button label has a dotted (or dashed?) border 
around it when the control is selected. However, the same does not hold 
true for labels of textboxes, even though they may still have access keys.

    Without an associated control, the control should probably just 
inherit the text styling, background, et cetera of the parent. 
Otherwise, the user agent vendor has to figure out what the default 
style should be without a point of reference in the OS. In fact, labels 
in many operating systems are just blocks of text, so treating 
unassociated <label> elements as nothing more than a kind of <span> 
element is probably best for most platforms.

>>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.
> 
> Do sites really use the <label> element and not associate it, though?  I
> mean, sure, they _omit_ the <label> element, but I can't think of any
>  case where I've just seen an empty one. Do you have any examples?

    I'd have to look for examples. I've lost track of where I've seen 
sites that don't do proper label association. I think you're right, 
though, in that it's far more common for people not to use <label> at 
all (which is annoying for radio buttons, et cetera). Most sites that 
use <label> seem to use it right. Oddly, Mozillazine.org seems to be 
using BOTH explicit and implied association for <label> elements AT THE 
SAME TIME!
Received on Friday, 10 December 2004 06:40:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:38 UTC