[whatwg] LABEL and radio/checkbox onclick

On 23 Aug, 2004, at 11:56 AM, Matthew Raymond wrote:
> ...
>> It raises a question, though, which is "how do you determine which  
>> form control is associated with the "Flavor:" label above?".
>
>    A <label> element is semantically worthless without an associated  
> control, because, fundamentally, a label actually has to label  
> something.

Similarly, a heading has to be a heading for something. And similarly,  
the <h1>-<h6> elements don't require you to specify exactly what part  
of a document they are a heading for. Worse, unlike <label>, with  
<h1>-<h6> you can't do so even if you want to.

If you're inventing new HTML markup, solving the ownership problem for  
headings (perhaps the way XHTML2 does, perhaps not) should be more of a  
pressing issue than solving the ownership problem for radiogroup  
labels. The former are considerably more (common * semantically useful)  
than the latter.

> ...
>> I really don't understand why you _want_ labels to do the wrong thing.
>
>    Wrong as defined by whom?

As defined by the vendors of GUI toolkits for the past 20 years, and by  
the resulting mental models in ~99 percent of those people who have  
ever used a computer.

> ...
>> That clicking a label element transfers focus is not a feature of  
>> HTML, it's a misfeature and almost certainly another example of vague  
>> and misleading comments in the spec, rather than actual intent from  
>> the authors of the HTML spec.
>
>    Horse feathers! From the spec:
>
> http://www.w3.org/TR/html401/interact/forms.html#h-17.11.2
>
>    "This example assigns the access key 'U' to a label associated with  
> an INPUT control. Typing the access key gives focus to the label which  
> in turn gives it to the associated control. The user may then enter  
> text into the INPUT area."

It is rather awe-inspiring for you to have misread either Ian's text  
above, or the spec text, or both, so severely that you really think  
they're discussing the same thing.

The former is about "clicking a label element".

The latter is about "typing the access key".

>    If it's unintentional, why to they go out of their way to mention  
> that the access key is passed from the label to the control?

Because (assuming accesskey should exist at all) the accesskey behavior  
is correct behavior, which is not the issue here. (Which is why Web  
Forms 2 doesn't even mention accesskey at the moment, except in its  
undescribed lists of attributes and interfaces.)

> Furthermore, look at the actual control in the example it refers to:
>
> <LABEL for="fuser" accesskey="U">User Name</LABEL>
> <INPUT type="text" name="user" id="fuser">
>
>    It's a TEXT BOX!!! Clearly, the focus passing behavior in the spec  
> is intentional.

Sure, but that's (1) for accesskey, which is not the issue here, and  
(2) badly described, because it implies that the label is necessarily  
focusable. The spec should just say "Typing a label's access key gives  
focus to the control associated with the label."

> ...
>    Saying that the HTML 4.01 label behavior is a mistake is one thing,  
> and there's a reasonable argument for that. Saying it was an accident  
> is ridiculous.

The mistake is not in any of the parts you quoted. It is here: "When a  
LABEL element receives focus, it passes the focus on to its associated  
control. See the section below on access keys for examples." This is  
faulty in two ways I have already described  
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/ 
001372.html>, and thirdly in that it expects <label> to be focusable in  
the first place.

> ...
>    True, but in most situations identical blocks of markup with  
> identical CSS properties render and behave the same. By going with the  
> native platform conventions, you force identical <label> markup to  
> behave (and possibly render) differently, solely because of the  
> associated control:

<option> is even worse: it has completely different behavior and  
rendering dependent not merely on its associated control (<select>),  
but on an *attribute* (multiple) of its associated control! Zounds.

> ...
>    Now suppose you want to style labels that pass the focus to their  
> associated controls. In HTML 4.01, it's simple. You just style  
> <label>.
>
>    How do you do the same when the behavior is platform specific? Do  
> you add a new CSS pseudoclass? Perhaps "focuspassing"?

If that was really necessary, then GUI toolkits would make such a  
distinction, and UAs would follow the toolkit's appearance in their  
default <label> rendering. There's no need for an author to fiddle with  
it unless they're trying to be confusing. And I would be surprised and  
disappointed if What-WG codified a new CSS pseudoclass, or anything  
else, that had the sole purpose of allowing authors to be confusing.

> If the native operating system has a specific style for labels that  
> pass focus, do you override the <label> styling if a style for  
> focus-passing labels isn't defined?
> ...

You probably need to specify whether by "do" you mean "should", "must",  
or "can", and whether by "you" you mean "UA implementors" or "Web  
authors".

-- 
Matthew Thomas
http://mpt.net.nz/

Received on Monday, 23 August 2004 07:05:50 UTC