[whatwg] LABEL and radio/checkbox onclick

[Matthew Thomas]

On 20 Jul, 2004, at 8:47 AM, Matthew Raymond wrote:
>
> Matthew Thomas wrote:
> ...
>> Read what I said. I did not say the specced behavior was faulty just 
>> on the Mac platform. I said the specced behavior was wrong "on any 
>> platform".
>
>    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.

>  This is not the same as a violation of native UI guidelines or 
> conventions. UI that exceeds what the OS can do shouldn't be 
> forbidden. Only UI that contradicts existing conventions in a 
> meaningful way should be avoided.

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.

Furthermore, good APIs and development environments are designed to 
encourage good interface design, hopefully making guidelines less 
necessary. If an API makes a functional but wrong interface design 
substantially easier than a functional and good interface design, the 
API is faulty. That applies just as much to HTML+WF2 as it does to .NET 
or Cocoa or anything else.

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

>>>     Web pages are a special GUI case where behavior needs to be as 
>>> consistent as possible across all platforms.
>>
>> That is incorrect. The principle of device independence "does not say 
>> that the user experience will be the same on every device" 
>> <http://www.w3.org/TR/di-princ/#DIP-1>.
>
>    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. Many 
groups of devices (for example, mobile phones produced by the same 
company) will share largely the same user experience.

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

> ...
>    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. And 
secondly, as convenient markup so that labels in a form can be styled 
consistently. (Ideally UAs would have label {font-family: caption; 
font-size: inherit} in their default style sheets, but even though they 
do not, using <label> for non-checkbox/-radiobutton form controls still 
makes consistent author styling easier.)

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

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

> ...
>> One of the browser vendors whose staff are contributing to this 
>> working group (Apple) produces a browser (Safari) that, in its latest 
>> release version, does support <label> at all.
>
>    Then Safari is non-compliant. Sadly, users will suffer because it 
> will become more difficult to use radio buttons and checkboxes as a 
> result, since they now have a far smaller target area to click on. 
> Compared to this, the focus issue is minor.

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

> ...
>> Yes: nothing at all. Users frequently click on (what they assume to 
>> be) non-functional parts of a GUI or a Web page as a form of 
>> doodling, while they're reading or thinking of what to write. Such 
>> clicks unexpectedly changing focus could produce undesirable results. 
>> For example, clicking on the label for a single-line text field 
>> (which would be non-functional if it was a native app) shortly before 
>> typing Enter would accidentally submit the form.
>
>    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.

-- 
Matthew Thomas
http://mpt.net.nz/