[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

Matthew Thomas wrote:
 >>    Are you suggesting we change HTML spec behavior here? If so, can
 >> you explain why this specific behavior is undesirable beyond the fact
 >> that it's not a standard Mac behavior?
 >
 > 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. 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.

 > Therefore, given that the What-WG is interested in making Web
 > applications more like native applications, it would be a good idea
 > for the WG to correct this error in the spec.

    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.

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

 > 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

    As such, the <label> element, as defined in the spec, is appropriate 
for implementation because it is rendered content and not a specific OS 
control. However, the control that it passes focus to does have to 
conform to the guidelines listed, and therefore the user agent should 
discard the passed focus if the specific control cannot have focus in 
that OS.

    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?

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

 >> 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? Why is it even relevant, since, as you say, most browsers 
support this? Clearly, the developer's browser in all likelihood will 
contain this feature.

 > As
 > another example, Internet Explorer and Netscape 4 do not add the value
 > of any particular submit button to a GET URI if the Enter key is
 > pressed, but Opera and Gecko browsers arbitrarily choose the first
 > submit button in the form.

    I don't see your point. Are you talking about inconsistencies 
between browsers? About vagueness in the HTML specification? I thought 
we were talking about how web standards should be written.

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

 >>    Besides, this kind of workaround is pretty silly just to avoid
 >> focus on controls when a label is clicked.
 >
 > That's why I said: "having to do that to work around a bug in the spec
 > would be pretty annoying".

    As I pointed out, there is virtually no reason for the webmaster to 
even care if focus is passed to the control, especially when in most 
browsers the label itself can't have focus.

 >> Was there some other behavior you wanted to happen when they click
 >> the label?
 >
 > 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? They wouldn't be clicking on the web page if they're hitting 
enter for a URL, because the address bar would loose focus. They 
wouldn't do it if they wanted a new line in a textarea, because the 
textarea would loose focus. Please explain a real world scenario where 
the above would occur.