[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

Ian Hickson wrote:
>>   From the specification:
>>
>>   "The LABEL element is used to specify labels for controls that do
>>not have implicit labels"
>>
>>   ...AND...
>>
>>   "Each LABEL element is associated with exactly one form control."
> 
> Neither of those is a conformance requirement, and thus neither can be 
> used to argue that the document above is conformant or not. Both are 
> either statements of intent or general truisms. The first seems to be a 
> statement of intent ("this is what we wanted it to do"). The second seems 
> like it was supposed to be a truism. 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.

http://dictionary.reference.com/search?q=label

>>   I'm not sure what you mean by the terms "valid" and "conformant".
> 
> "Valid" means "syntacticaly correct according to the DTD", which is a 
> subset of "conformant".
> 
> "Conformant" means "conforming to the spec's conformance requirements".

    So, by these definitions, would an empty, unused <datalist> element 
be valid and conformant?

>>   On the other hand, you can easily make <label> behave like it does in 
>>most operating systems by simply using text instead of the <label> 
>>element. Why try to eliminate a feature of HTML when the web authors are 
>>fully capable of dealing with and problems by making trivial changes to 
>>markup?
> 
> I really don't understand why you _want_ labels to do the wrong thing.

    Wrong as defined by whom? Changing the behavior introduces as many 
problems as it solves. You're just gambling that the new set of problems 
will be less critical.

> Using text instead of <label> elements is semantically poor (at best) or 
> even plain wrong (at worst) and prevents static analysis user agents like 
> robots and screen readers from giving their users an optimal experience. 
> (That's another way of saying "it breaks accessibility".)

    Agreed. This has been brought up in previous conversations, and is 
one of the main reasons why I invented the input-redirect CSS property 
in the first place.

> 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."

    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? 
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. Why else would you give <label> an |accesskey| attribute 
int he first place?

    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.

> One of the best things about strongly semantic markup like HTML's is that 
> it can automatically adapt to the environment, rendering appropriately 
> whatever the operating system or platform. On some platforms, buttons can 
> take focus; on others, they can't. On some platforms, labels can be 
> activated and cause focus to be transfered (or even more, e.g. a checkbox 
> to get checked); on others, they can't. Some platforms have labels that 
> apply to some elements; others, other elements.
> 
> The beauty of HTML and semantic markup is that the _same_ source document 
> can result in correct, platform-convention-following interfaces whatever 
> the actual platform is, without the author having to even know the 
> platform exists, let alone what conventions it has.

    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:

<label for="control">Control: </label>
<input type="checkbox" id="control">

<label for="control">Control: </label>
<input type="text" id="control">

    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 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?