[whatwg] LABEL and radio/checkbox onclick

[James Graham]

Matthew Raymond wrote:
> James Graham wrote:
>
>> Native apps aren't going away. Having a
>> discrepancy between the behavior of native apps and web-apps is 
>> confusing.
> 
> 
>    Yes, I'm overwhelmed by the flood of users who are constantly
> complaining about the label focus passing issue in Internet Explorer,
> Mozilla and Opera... NOT!

Yay! Sarcasm!

>> Worse, it may vary withn a single application (if
>> some screens are HTML and others are native) - this will always be 
>> true for the web browser itself, for example.
> 
> 
>    I sincerely doubt that applications will use the exact same controls
> in the same window but have on implemented as HTML and the other as
> native code. At best you could call this situation extremely uncommon.
> Personally, I've never seen it.

Er, so it's OK to have different behavior on two different screens of 
the same application but not on the same screen of the same application? 
What about having one behavior for widgets that sit on the desktop but 
another for desktop-related applications (e.g. the file browser)? 
Several OS's allow or plan to allow HTML widgets on the desktop.

> 
> Interestingly enough, the Mozilla UI obeys the same
> label focus passing convention that's in HTML.

That sounds like a bug (it's probably a result of the fact that Mozilla 
is cross-platform and so has a hard time getting platform-specific UI 
right, to the detriment of its usability).

> 
>> 2) It prevents optimisation of the interface to the device being used. 
>> For example, a small-screen device may choose to optimise the display 
>> of a form for the small screen by reducing the width of the field and 
>> label so they fit side by side. The text in the label would overflow 
>> and the user would be able  to read the full text by focusing  the 
>> label and scrolling using some sort of nipple (this probably isn't a 
>> great example but it's illustrative of a general point). Mandating 
>> that focus from the label element passes straight to the control 
>> prevents this kind of adaptation to the device in question.
> 
> 
>    This is the best argument I've heard yet, and I have to admit it has
> some merit to it. Unfortunately, it ignores the fact that many labels in
> HTML don't use the <label> element at all. They just use text. As a
> result, the use of focus you describe above may not be possible for many
> web control labels.

You're taking down the specific example whilst ignoring the general 
point. For maximum usability, web apps should adopt the interface 
conventions of the platform on which they run and the specifcation 
should avoid requiring a specific UI behavior anywhere. This is quite 
important for visual UAs and extremely important for non-visual UAs and 
small devices since they might have very different requirments and 
limitations compared ttoviisual browsers.

> 
>    It also ignores the fact that the HTML specification has had the
> focus passing in it for nearly five years. Why would someone design a
> the UI for a web-capable device that ignores such an established web
> standard?

Because the standard specified behavior that would impair the experience 
of users on that device.

>> So? The fact that one has the ability to make a certian UI doesn't 
>> mean that one /should/.
> 
> 
>    Why should one make labels inconsistent with regards to how they
> behave in conjunction with controls? Creating UI consistency doesn't 
> sound like something we shouldn't do.

But we'd be creating inconsistency with the majoriy of the user's apps. 
If a specific behavior is problematic or suboptimal, it should be fixed 
at the OS level.

> 
>> From the point of view of the user, there is no
>> difference between the fake-assosiation of native label/control combos 
>> and the 'real' assosiation of the webapps label/control combo and so 
>> they should have the same behavior.
> 
> 
>    This is an assumption that is not necessarily based in fact. For
> checkboxes and radio buttons in Windows XP, if you place your cursor
> over the label, the button lights up. The same is not true for simple,
> unassociated text next to a text input control. That is a clear
> difference in the presentation of the UI.

You've missed the point. The user has no way of knowing why some 
applications behave one way and some behave another. From a UI point of 
view, arguments based on the underlying toolkit are unhelpful.

>>>> Firstly, to identify the control for accessibility software.
>>>
>>>
>>> Isn't that similar to the |title| attribute?
>>
>>
>> Well, not necessarily. For a start, the 'title' attributte isn't 
>> commonly displayed. Also, in certain contexts, it does make sense to 
>> move focus from the label to the control - e.g. I have a firefox 
>> extension [1] which provides a list of accesskeys defined on the 
>> current document, and  allows the element assosiated with each 
>> accesskey to be focused. For accesskeys defined on label, I focus the 
>> assosiated form element, since this is almost always the most useful 
>> thing to do in this case.
> 
> 
>    I must have missed something. Why would you need to set the focus to
> the label instead of the control in this situation? What is the utility
> of that?

Sorry, I haven't been clear. In that specific case, I use the behavior 
you advocate i.e. given:
<label for="somecontrol" accesskey="k"><input id="somecontrol">, I pass 
the focus to the input element (this isn't from a click event on the 
label but from a doubleclick event in a listbox containing a list of 
accesskeys and descriptions of the key functions based on information 
provided in the markup). This doesn't conflict with user expectations 
because there is no OS standard (although the behavior is the same as 
that provided by the browser - in fact, if I knew how to access the 
underlying browser code to process accesskeys I wouldn't have written 
any accesskey handling code at-all, just code to create a list and 
descriptions of such keys) and because the user has no idea where the 
keys are defined, just what they should do.

>> But if it differs at all, we shouldn't specify one way that authors 
>> will assume they can rely on.
> 
> 
>    That depends on the how it differs. The UI for a small device may not 
> be optimized for use with web pages or web apps. In that situation, 
> differences in UI for browsing may actually be necessary.

Then they are up to the browser maker to implement. You can't seriously 
propose standardising some nonstandard UI behaviour because "on some 
devices the native UI might not be perfect for webbrowsing"!

>> The absence of function is itself a behavior.
> 
> 
>    No, it's a lack of a behavior, and in the case of label focus
> passing, it only serves to decrease functionality.

Do you also believe that the whitespace on the Google homepage is a lack 
of behavior which decreases functionality? An absence of function is a 
design choice in the same way that a function is and should not be 
treated as a mistake needing to be fixed.

I hope I have succeeded in conveying why I am opposed to specifying 
/any/ particular UI in the specifcation rather than just focusing on 
this one issue.


-- 
"If anybody ever tells you that you’re using the language incorrectly, 
just yell 'prescriptive grammarian!' at the top of your voice and all 
the linguists in the building will run over and surround the guy... and 
then they’ll rough him up"