[whatwg] LABEL and radio/checkbox onclick

[James Graham]

Matthew Raymond wrote:

> Matthew Thomas wrote:
>
>>>    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.
>
>
>    I should point out that I hate the heading elements. They serve no
> practical purpose other than formatting, 

If used properly, they can be used to construct a document outline. I 
agree that they're not that well designed although they do offer a 
little flexibility not found in the XHTML 2 model. But this is way off 
topic.

>     I generally agree, but, with regards to <label>, the only issue is
> that the spec writers neglected to use the word "must". Otherwise, the
> semantics of <label> and how to make an association with a control are
> spelled out clearly.

The assosiation between label and control is primarilly so that users of 
non-visual UAs can tell which label goes with which control.

>>>> 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,
>
>
>    The logic here is flawed. It assumes both that GUI API and toolkit
> developers are infallible,

No, it assumes that changes to the toolkit should be made at toolkit 
level. HTML provides a means for specifying the structure of the toolkit 
elements (in a form or application), not the toolkit itself. Either 
complain to toolkit vendors or wait for XBL to be widely deployed so you 
can create your own non-native toolkit and confuse users all you want.

> It also
> assumes that many elements of the GUIs were the result of conscious,
> thorough and intentional decision making, which you do not produce
> evidence for.

And you did not produce evidence against. (actually I did produce 
circumstantial evidence in favour of the position this was a decision 
rather than negligence but that's hardly conclusive).

>    (Interestingly, there also seems to be the implication that the
> browser shouldn't be a platform in itself. I'd be interested in hearing
> people's opinions on this...)

The browser shouldn't be a platform in itself. We have enough platforms. 
I think jwz was wrong;  these days just reading email isn't enough, 
every piece of software expands until it's a general-purpose platform. 
HTML is only a "platform" in the rather limited sense described above; 
i.e. it allows native (or native-like) widgets to be arranged and allows 
scripting of events triggered when the user navigates those elements.

>>>    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.
>
>
>    <Label> elements are associated with their controls. Therefore, for
> presentation of an access key in a <label>, the user agent need only
> obtain the access key from the associated control. Instead, the
> recommended method is to put |accesskey| on the <label>. This means
> that, on a semantic level, the access key is passed from the label to
> the control, which reinforces the concept of passing focus.

Reenforces for whom? The case with accesskey is entirely different to 
the case for click events because the user has rather specific knowledge 
of which element is targeted by a click but rather limited knowledge of 
which elements have accesskeys assigned. It is entirely reasonable that 
the behavior is different because, from the point of view of the user, 
the actions of using an accesskey and clicking a label are different. 
The only change that is really needed is that, when an accesskey 
specified on a label is used, the focus goes directly to the control 
rather than passing through the label.

>>> 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,
>
>
>    It is the issue, because, according to the specification,
> |accesskey| give focus to the <label>, not the control. The <label> give
> focus to the control through focus passing.

Since we're improving this anyway there's no need to rely on the HTML 4 
behavior. I would be *very* surprised if any pages broke because the 
control label didn't generate any focus events when accesskeys were 
used, especially given that accesskeys are so rarely used in the wild.

>> The spec should just say "Typing a label's access key gives
>> focus to the control associated with the label."
>
>
>    What is implied in the HTML 4.01 spec is that all input is
> redirected to the associated control. Why else have |accesskey| on
> <label> and make the use of |accesskey| with <label> the recommended
> method? Due to the |for| attribute and its ability to allow multiple
> labels to be attached to the same control, it is clearly not as an
> alternative way of assigning an |accesskey| value to the control.

I don't understand the difference between the proposed solution and the 
behavior you describe. I believed that HTML 4 specified that accesskeys 
should be defined on labels for accessibility reasons; the label 
contains a description of the control that can be used to describe the 
behavior of the accesskey.  If the control has multiple labels and the 
accesskey is defined on the control, it is much more difficult to 
extract a description.

>
>>>    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>,
>
>
> "The W3C is frequently wrong about UI details. Here, for example,
> firstly they failed to recognize that in native applications on any
> platform, clicking the label for a listbox (aka <select multiple>) or
> text field will not focus the field."
>

>
>    So you your argument is really only valid with reference to whether
> or not focus passing is a native behavior, not whether it's useful.

Have I mentioned that useful toolkit behaviors should be implemented by 
the toolkit vendor? The Gtk people would probably consider a patch!

>>>    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.
>
>
>    So, effectively, you're arguing that native styling be enforced for
> all UI, regardless of markup or CSS?

We're not talking about style but behavior. That's different. However, 
in general, I would prefer native-looking form controls. Designers seem 
to disagree. In my experience styling form controls often (but not 
always) impairs the usability of a page.

>    Ah, but I see your argument: You can't know whether the style is
> confusing on a specific operating system. Therefore, if webmasters want
> non-native behavior, they should have to build their own widgets so as
> to discourage them from using non-native UI.
>
>    The problem with this is two-fold. First, vendors may simply ignore
> the spec changes, or add proprietary extensions, if the lack of styling
> becomes too unpopular. Second, XBL2 will probably be released by the
> time WF2 makes it through a standards body, so webmasters will likely
> reuse XBL2-based widgets that require little more than a line of CSS 
> to use.

It is entirely true that XBL will allow people to shoot themselves in 
the foot. However a significant difference is that user stylesheets can 
override XBL bindings but cannot override the browser defaults (well, in 
theory, users could build their own native-like widgets but that's 
pretty unreasonable). Therefore it's important that the default behavior 
from HTML alone is as intuitive and native-like as possible.

>    When this happens, a lack of flexibility in HTML elements may result
> in their disuse in favor of XBL2 widgets, resulting in a semantic
> deterioration of the web.

Unless XBL has changed beyond all recognition in the W3C, it's still 
possible to bind XBL to semantic elements e.g. I could bind my custom 
label element to all label tags. In the hands of responsible authors XBL 
doesn't lead to semantic degredation any more than CSS.

>>> 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".
>
>
>    Clearly, "you" can't be the webmaster, otherwise he/she wouldn't
> have left out the styling. As for the rest, you're overcomplicating the
> question. The bottom line is that you have a styling conflict with the
> generic <label> styling and the platform-specific styling that only
> occurs with specific controls. I was asking about a method of solving
> this conflict without regard for whether the specific method should be
> required in spec (which is a somewhat separate argument).

If some OS allows foucs passing on certian elements, the UA vendor 
should be free to implement that (as is the case at present). If those 
elements have a particular style, that should be applied by the UA. If 
the author defines some style for generic labels, the CSS cascade sorts 
out the style that actually finally gets applied. If the UA wishes to 
veto any author styles, that's OK too.