[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

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, and they force the webmaster to
determine the level of the header rather than providing an automated
means. If anything, headings should work like this:

<section>
   <heading>Header 1</heading>
   <p>Content for 1.</p>
   <section>
     <heading>Header 1a</heading>
     <p>Content for 1a.</p>
   </section>
   <section>
     <heading>Header 1b</heading>
     <p>Content for 1b.</p>
   </section>
</section>

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

>>> 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, and that user needs and technology haven't
changed in twenty years. Neither is necessarily the case. 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.

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

> and by
> the resulting mental models in ~99 percent of those people who have  
> ever used a computer.

    As far as mental models go, you're oversimplifying the situation.
People have a mental model that if you move your mouse over text and it
changes, it must do something. Windows XP actually highlights checkbox
and radio button controls as you move your mouse over their labels.
Furthermore, making all labels focus their controls would create a
stronger association in the user's mind for controls that already allow
this behavior.

>>> 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."
> 
> 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.
[Snip!]
Actually, I misread Ian's text. However, since mouse users typically
focus an item by clicking on it, focus passing for that situation is
implied.

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

    Not read the the spec again (emphasis added, by the way):

   "Typing the access key gives _FOCUS_ to the label which in turn gives
it to the associated control."

> (Which is why Web
> Forms 2 doesn't even mention accesskey at the moment, except in its  
> undescribed lists of attributes and interfaces.)

    WF2 doesn't mention access keys because we haven't fully discussed
them in the mailing list. We have yet to come to any consensus on the issue.

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

> and
> (2) badly described, because it implies that the label is necessarily  
> focusable.

    Sounds to me like you're using one HTML behavior you don't like
(non-native focusing of labels) to defeat a related behavior you don't
like (focus passing).

    Out of curiosity, how does someone using a keyboard select
unfocusable controls? (Especially if there's no presentation of access
keys.) Surely, you'd have to be able to give focus to a control for
accessibility reasons. Are you sure we're not talking about an OS
deficiency?

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

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

    When a control is in a container with scrollbars, it's common for
clicking a control to result in scrolling of the container to make the
entire control visible. Now, picture a situation where the control isn't
even within the visible section of the container, but the control's
label is. By clicking a focus-passing label, the user has easy access to
the control. However, once the user has to scroll to get part of the
control in the visible area of the container so they can select it,
their first impulse is to make the entire control visible while
scrolling, in spite of the fact that it would be quicker to just get
part of it visible and click that part (since they have to click the
control to give it focus anyway).

    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.

"Secondly, they failed to recognize that in all extant versions of Mac
OS, most native controls (including checkboxes, radio buttons, and
option menus) could *never* be focused, even when you clicked on them.
The same is true even in OS X, unless you have 'Full Keyboard Access'
turned on, which most people don't since it's (a) off by default and
(b) intended for disabled people. (Apple's designers judge, probably
correctly, that non-disabled people are faster overall if focus is
confined to controls for which text input is actually useful.)"

    A simple solution would be to simply have <label> pass a greater 
number of events (like |onclick|), but only pass events that the 
associated control supports. If the control supports |onclick|, the 
<label> would pass click events, but if the control can't be focused, 
<label> would do nothing. This would result in backwards compatibility 
with HTML 4.01 in the vast majority of circumstances, and most browsers 
wouldn't even have to change their code.

> and thirdly in that it expects <label> to be focusable in  
> the first place.

    You just repeated your second argument.

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

    The difference here is that <option> inherits properties from it's
parent, <select>. By contrast, native behavior would require that
<label> inherit behavior from a child control element, and that's
assuming you're using implicit association. If <label> is using |for| to
create an association, <label> could exist almost anywhere in the document.

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

> There's no need for an author to fiddle with
> it unless they're trying to be confusing.

    This isn't an argument against pseudoclasses for labels of focusable
controls; this is an argument against using HTML and CSS to produce UI
that breaks with convention, which is common practice on the web. While
you could argue that a new pseudoclass like the on I described (but
wasn't necessarily suggesting) could be abused in a manner that confuses
the user, this does not mean that all instances of styling are confusing.

    For instance, Mozilla has CSS that supports rounded borders. Suppose
you want the focus border around a checkbox's label to have rounded
corners instead of rectangular. The rounded borders don't really
interfere with the user's understanding of what the control does or how
it functions.

    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.

    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.

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

    No, the purpose is to allow authors styling options.

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