[whatwg] LABEL and radio/checkbox onclick

[James Graham]

Matthew Raymond wrote:
> Matthew Thomas wrote:

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

The point:
1) It confuses users. Native apps aren't going away. Having a 
discrepancy between the behavior of native apps and web-apps is 
confusing. Web apps may also be deployed to appear to be real apps Many 
windows applications use mshtml.dll to render parts of their interface, 
Apple are using KHTML to render desktop widgets, and so on. Therefore, 
from the point of view of the user, any behavioral differences between 
web-apps and native apps is entirely arbitary and mus be learnt on a 
case-by-case basis. 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.

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.


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

Can you demonstrate that:
1) This UI is functionless on all web-capable devices and will remain so 
in the future?
2) Providing function for all areas of the UI improves the user 
experience (as mpt demonstrated, this particular function has the 
harmful side effect of increasing the probability of erronous form 
submission, so you'll need to show, at least, that this is either not 
the case or that the benefit of dfferent behavior outweighs this problem).

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

So? The fact that one has the ability to make a certian UI doesn't mean 
that one /should/. 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.

> 

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

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.

>> And
> 
>> secondly, as convenient markup so that labels in a form can be
>> styled consistently.
> 
> 
> That can be done with <span>

So? We can do away with all non-replaced elements and use <span> instead 
- it's not convenient or useful.

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

But if it differs at all, we shouldn't specify one way that authors will 
assume they can rely on.


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

The absence of function is itself a behavior.


[1] http://forums.mozillazine.org/viewtopic.php?t=84015 - the extraction 
of descriptions could be improved.

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