[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

Matthew Thomas wrote:
>>    I presume that "wrong" means it's not commonly done in the native UI.
> 
> In this case it means it's *never* done in the native UI. So doing it 
> would be surprising-and-not-in-a-good-way.

    The only thing about it that surprised me was that clicking on the 
label did anything at all for textboxes and text areas, and that was 
because I'd never clicked them. I hear a lot about how people will get 
confused and accidently perform some action that is catastrophic, but 
I'm not hearing a lot of people saying that actually happened to them.

    I'd also like to point out that the function of labels can be more 
clearly indicated using CSS. For instance, with implicitly associated 
controls, you can have the label text and the control border change to 
the same color when you put your mouse over them.

    Furthermore, all UI was originally never in an OS. You are once 
again creating a blocking condition that prevents all new UI from being 
incorporated into a browser before it's a native feature of the OS.

> Interface guidelines typically warn against only the most common 
> mistakes made by developers. Very many wrong things are not expressly 
> forbidden in the guidelines for a platform, because the platform vendor 
> assumes that developers will not be stupid enough to try them. A 
> platform vendor must take that approach, because if it did not, the 
> guidelines would need to be much larger, more expensive, and harder to 
> use themselves.

    Hmm, I thought you were actually going to explain what is stupid 
about label focus passing rather than just being sarcastic.

>>    The goal of WHAT-WG is to create new technologies for use in web 
>> applications. That has nothing to do with ensuring the applications in 
>> question look like the OS.
> 
> We were discussing behavior, not look. It would be less offensive 
> (though still annoying) for Web form elements to behave differently from 
> native form elements if their different behavior was advertised by a 
> markedly different look. But it's probably too late to require that, as 
> most of Safari's and Opera's form elements already look native.

    I'm sorry, other than picking apart my trivial choice of the word 
"look", what was your point?

>>    There's also nothing that says it has to be DIFFERENT on every device.
> 
> I did not ask, and am not asking, for the user experience to be 
> different on every device. I am asking for the user experience for any 
> device to match that expected by regular users of that device.

    The label focus passing on any OS that doesn't support it is a 
superset behavior. An otherwise functionless piece of UI is given a 
function. How does that disrupt the user experience in any OS?

>>> On the contrary, the WAI User Agent Accessibility Guidelines say that 
>>> user agents should "[o]bserve operating environment conventions for 
>>> the user agent user interface, documentation, input configurations, 
>>> and installation" 
>>> <http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-conventions>.
>>
>>
>>    Because this refers to the "user agent user interface", this only 
>> applies to user interface elements "that are not created by content". 
>> See this URL:
>>
>> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-ua-ui
> 
> 
> ... Which refers for "more information" to 
> <http://www.w3.org/TR/WAI-USERAGENT/conformance.html#content-or-ua>, 
> which says that "everything that is not content" includes "the user 
> interface focus". Therefore, the user interface focus should observe 
> operating environment conventions.

    This is in the context of "user agent features only", and since the 
feature is defined as part of HTML, it is not a feature specific to the 
user agent.

 > On all widely-used platforms, it is a
> convention that clicking a label (other than a checkbox or radiobutton 
> label) does not alter the user interface focus.

    This is largely because the "label" in most of these UIs is merely a 
text block. The text isn't next to a control because it is associated 
with the control at the API level, it's merely placed there by the 
programmer. The association between the text and the control is all in 
the user's head.

    Radio buttons and checkboxes are different. In those cases, the 
"label" is part of the control, and has a direct, preprogrammed 
association with the control. This is much closer to what a <label> 
element really is. It's text that has a direct association with the 
control. The label element is, therefore, not the same as the text 
blocks used in some native UI and should not be treated as such.

>> ...
>>    My interpretation of the intent of the guidelines on this matter 
>> are that web authors should be free to specify a behavior in the 
>> content, but whatever UI is not specifically specified by the web 
>> author is to be presented according to OS conventions. It would seem 
>> to me that when using a <label>, you are specifying a behavior at some 
>> level, or else what's the point of using <label> to associate the text 
>> with the control?
> 
> Firstly, to identify the control for accessibility software.

    Isn't that similar to the |title| attribute?

 > And
> secondly, as convenient markup so that labels in a form can be styled 
> consistently.

    That can be done with <span>, and in many cases labels aren't styled 
at all.

> ([...] using <label> for non-checkbox/-radiobutton form controls still 
> makes consistent author styling easier.)

    This is inconsistent. You want labels for one type of control to 
behave one way, while for other controls it behaves differently, yet you 
want the user to have no way of visually distinguishing between these 
two functionally different label types. To me, that sounds like bad UI.

    I would like to point out that when I was first becoming accustom to 
Windows, I was unaware that clicking on the label for a checkbox or 
radio button was the same as clicking on the control directly.

 >>> For example, one of the browser vendors whose staff are contributing
 >>> to this working group (Opera) specializes in producing browsers for
 >>> mobile phones. It would be inappropriate for forms to behave exactly
 >>> the same on mobile phones as they do on desktop computers, since the
 >>> latter are likely to have much more convenient pointing devices.
 >>
>>    In the case of lacking a good pointing device, how is focus a 
>> problem? You can't click on the label, and if you tab to the control, 
>> it won't stop on the label whether it passes focus or not, because 
>> it's not a control.
> 
> That was not an example of focus behavior. It was an example of how UA 
> behavior in general can and should differ between devices.

   No, device UI behavior in specific cases can and sometimes should 
differ between devices. In general, device behaviors should always 
retain at least a degree of consistency to that users don't have to 
learn a new system from the ground up every time they get a new device.

>>>> Web authors need to know that the way their page behaves on their 
>>>> own platform is going to be the the same on all other platforms.
>>>
>>> It's far too late for that. For example, since the beginning of the 
>>> Web, almost all graphical browsers have allowed people to turn off 
>>> images.
>>
>>   What does this have to do with behavior on different operating systems?
> 
> Simply that if different browsers can have different behavior even on 
> the same platform, it is unreasonable to expect them to have the same 
> behavior on different platforms.

    Different browsers don't necessarily support the same standards. 
Failure of a specific browser to be standards compliant is not 
necessarily a good reason to change the standard. Furthermore, many 
browsers do obey HTML specs regarding label focus passing, so are you 
suggesting that these vendors should have to remove this support in 
order to be WF2 compliant?

> That's right. <label> should be implemented in Safari. But that should 
> not require contravening normal behavior for non-checkbox/-radiobutton 
> labels.

    You advocate the absence of a behavior for non-radio button and 
non-checkbox controls. Therefore, what behavior are we contravening?

>>    Why would you be hitting enter while randomly clicking on places on 
>> the form?
> 
> I did not say "while typing Enter", I said "shortly before typing 
> Enter". For example, someone may be absent-mindedly tapping at the 
> (apparently neutral) area of the "To:", "CC:", and "BCC:" labels in a 
> Webmail app while he tries to decide whether to add anything further to 
> the message.  He remembers something else he must write about, so he
> presses Enter to start a new paragraph. If <label> behaves like it does 
> native apps, nothing happens -- the textarea has lost focus, and no form 
> element is focused, so nothing happens until he realizes his mistake. 
> But if <label> behaved the way you wanted it to, one of the address 
> entry fields would be focused, and since those are single-line text 
> fields, pressing Enter would send the message prematurely.

    So he was previously typing a message in a text area when he moves 
his hand from the keyboard to the mouse and suddenly starts clicking on 
random places in the web page without realizing that this will take 
focus away from the text area. Then he hits enter for a new line without 
seeing where the text cursor is, or the fact that it's no longer there, 
since the text area has lost focus.

    So, effectively, you're combining an unlikely nervous behavior with 
the unlikely event that the user will click specifically on a label by 
accident while at the same time not being aware of at least one existing 
OS behavior and one browser behavior. Recall also that labels are 
"apparently neutral" because that is the default style in many browsers, 
not because it is in the specification.