[whatwg] LABEL and radio/checkbox onclick
mpt at myrealbox.com
Mon Aug 23 07:05:50 PDT 2004
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
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:
> "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
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
> 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
More information about the whatwg