[whatwg] LABEL and radio/checkbox onclick

[Ian Hickson]

On Sun, 22 Aug 2004, Matthew Raymond wrote:
>
> 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

That isn't a normative reference either. :-)

A <label> element with no referenced control is indeed semantically 
worthless. So is an empty <li> element or a <form> that contains no form 
controls. However, they are all allowed.


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

Yes.


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

The platform UI guideline authors.


> Changing the behavior introduces as many problems as it solves. You're 
> just gambling that the new set of problems will be less critical.

The behaviour hasn't been changed. The text in Web Apps 1.0 doesn't 
contradict the text in HTML4.


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

I don't deny that the accesskey attribute should work on <label> elements. 
The WA1 spec even mentions it explicitly.


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

I was referring to the idea that clicking the label should forward focus. 
But as I later realised, and pointed out here, the HTML4 spec doesn't 
require that anyway.


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

Render, yes. Except that CSS applying to form controls isn't defined. 
Behave? Not at all, at least not yet. It's one of the reasons XBL is being 
defined, of course.


> By going with the native platform conventions, you force identical 
> <label> markup to behave (and possibly render) differently, solely 
> because of the associated control:

Yes. This is a feature, not a bug. It makes HTML applications fit into the 
native OS as first-class citizens instead of making them inconsistent with 
other user applications.


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

HTML4 doesn't normatively define how <label> elements can ever get focus. 
So no, it's not that simple. There's in fact no guarentee that two 
examples of using <label> with controls will work the same.


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

Why would you want to do this? I don't understand the use case.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'