[whatwg] LABEL and radio/checkbox onclick
Matthew Raymond
mattraymond at earthlink.net
Sun Aug 22 16:56:55 PDT 2004
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?
More information about the whatwg
mailing list