[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

James Graham wrote:
> 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.

    In theory, they can be used to construct a document outline. In 
practice, they could be replaced by <span> or <font> elements and 99% of 
the time no one would know the difference.

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

    This is revisionist. Clearly, the spec intends for the association 
to be used for focus passing, especially with regard to passing the 
focus that's caused by access keys. Furthermore, I did a quick test of 
Mozilla, IE and Opera on my system, and none of them associated a 
<label> with the nearest control (with regard to focus passing) in cases 
where the documented association methods were not used.

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

    This is working under the false assumption that browsers use OS API 
or toolkit widgets, which is not the case for Internet Explorer and 
Mozilla, which use custom widgets. Changes to browsers with custom 
widgets would be necessary in order to support changes to the behavior 
defined in HTML 4.01.

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

    Why should I produce evidence when I'm not the one who wants to make 
a change to a five year old behavior supported by the majority of HTML4 
browsers? Remember that we're talking about a behavior that replaces the 
absence of a behavior, so you need to argue not only that the platform 
developers specifically chose to exclude it, but were opposed to other 
vendors adding the functionality to their programs.

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

    I don't really support HTML as its own platform either (although I'd 
be interested in seeing an OS where the GUI is based entirely on a 
superset of HTML or similar). However, I don't necessarily agree with 
reducing HTML functionality to a subset of the native platform. If an OS 
doesn't have the GUI elements necessary for proper use of web pages and 
applications, the vendors should not be prevented from implementing 
custom widgets and behavior to address the problem. There is a line 
where that could go to far, and vendors could end up creating platforms 
and confusing users, but I don't believe that <label>, in its current 
form, crosses that line.

>>>>    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
> 
> 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 doesn't matter. The way the specification is written, the <label> 
element's actual access key is NEVER passed to the control. FOCUS is 
passed to the control. Therefore, any changes to the specification with 
regard to focus should also address access keys.

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

    Not really. Invoking the access key gives focus to the control. 
Clicking on a label for certain kinds of controls gives focus to the 
control. The only leap the user makes in their minds is that sometimes 
all the labels focus controls instead of just a few, and this concept 
can be facilitated by default styling.

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

    Actually, in the case of native focusing behavior, it would be 
better to say that the access key is passed 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.
>>>
>>> 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.

    I've heard this argument before. It doesn't matter if the page 
breaks or not. Saying something is good because it doesn't cause the 
heavens to open up and rain fire down upon us is a rather weak argument.

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

    What's your point? This wasn't the scenario I outlined anyway. In 
theory, each <label> can have it's own access key, so multiple access 
keys can (indirectly) give focus to the control.

    Besides, in the situation you describe, the UA can simply use the 
text of the first label, or the contents of the |name| attribute.

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

    Yes.

> The Gtk people would probably consider a patch!

    Got the website or email for that?

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

    No, in this case I think he was talking about using native 
conventions for widget styling.

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

    I'm not arguing that native styling shouldn't be used as the 
default. I'm just saying that webmasters will find a way to make a web 
page look the way they want regardless of what styling requirements we 
impose, so I don't see a point in making trying to make it nigh 
impossible for them.

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

    Well, I already proposed a CSS property ("input-redirect") that 
would give the user the kind of control you're talking about, but some 
people are opposed, especially purists that want to keep a separation 
between semantics, functionality and presentation. Of course, there's 
nothing preventing browser vendors from providing a stitch to turn on 
native support, regardless of CSS or markup.

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

    This is not entirely accurate. For instance, a UA for the blind may 
still use CSS, and therefore the UA may also use XBL. In fact, XBL may 
be a powerful tool for the blind if used correctly. As a result, this UA 
may in fact render the post-XBL content rather than the actual label, 
bypassing any semantic value of the <label> element.

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

    The problem with this scheme is that, no matter how the UA vendor 
decides to handle native styling, the webmaster still can't define 
separate styling for focus-passing and non-focus-passing labels. With 
the old system, they're all focus passing, so there's no guessing about 
how to style what.