[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

James Graham wrote:
>>    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!

    True, sarcasm is not the best tool in a professional forum. My
underlying point stands though. The only evidence I find that indicates
this is a problem are the posts on this mailing list.

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

    I find it strange that the developer wouldn't just use either HTML
or native GUI exclusively. Furthermore, the developer is in a position
to resolve those inconsistencies her/himself by using a small amount of
code to add the needed functionality.

> What about having one behavior for widgets that sit on the desktop but 
> another for desktop-related applications (e.g. the file browser)?

    What about having one widget with on behavior regarding labels and
another widget with another behavior? You're just trading one
inconsistency for another.

> Several OS's allow or plan to allow HTML widgets on the desktop.

    Do they plan to support HTML 4.01 or some future version of HTML
that may or may not exclude <label> focus passing? If the former, people
will be confused by the sudden removal of functionality from their HTML
widgets when "HTML 5.0" comes out.

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

    I doubt it. More likely it was a design decision. There's little
incentive for a cross-platform UA team to program in control behaviors
that conflict with each other. You can try adding a bug on
bugzilla.mozilla.org, though. There doesn't appear to be an existing bug
that matches this.

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

    How does this promote maximum usability? What it promotes is
usability no greater than that specified in the native GUI guidelines.
In the specific case of <label>, the only usability issue is the
preservation of text labels as behaving effectively like whitespace,
presumable to protect the user's g*d-given right to click in random
places for no reason.

    Also, recall that <label> is not the same thing as a label. The
element's function is to associate text with a control, not to format
text as a label. The latter is just a side effect of CSS. When we talk
about <label> the element, we're talking not so much about a behavior so
much as a widget. No one would argue that if the native environment
didn't have hyperlinks that they should be dropped from browsers.
Similarly, just because the OS discriminates with regard to what
controls can have labels as an actual part of their UI doesn't mean HTML
should.

    As defined in HTML, <label> is identical to a checkbox or radio 
button label. HTML simply liberates it from being control-specific.

> 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 [to visual] browsers.

    Non-visual UAs are not affected by the specification of UI-centric 
functionality, unless you're claiming that the HTML specification is 
implying that visual UI is required.

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

    This is chicken and the egg, here. The device vendors create a UI
for a web-capable device that ignores the HTML specification, therefore
the HTML specification should be changed. Furthermore, no one's actually
given me an example of this on a real 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. 

    That would depend on the individual applications the user has, but
statistically, there is a literal inconsistency.

> If a specific behavior is problematic or suboptimal, it should be fixed 
> at the OS level.

    Thus creating a situation where the UA vendors are at the mercy of
the OS vendor for creating better UI in web applications. The point of
consistency is to avoid confusion, not impair functionality.

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

    But users do have a way of knowing when labels exhibit the HMTL 4.01 
specified behavior. It happens only in browsers. There are many software 
publishers that use refinements to UI that aren't strictly according to 
OS conventions, and users are typically not confused by these 
differences so long as the differences are not difficult to perceive and 
understand.

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

    What does that have to do with the utility of label having focus
when the control does not?

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

    Access keys are another story, and I'm still considering how they
could be improved to resolve such problems. A list like the one you
describe would be nice, perhaps in the form of a navigational menu where
the labels are shown and the access keys are highlighted. If the control
had the access key, the control's |name| property would appear in the menu.

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

    Why are we altering existing specifications for web standards to
support devices that are significantly suboptimal for web browsing in
the first place? Perhaps we are trying to justify putting the web on 
every device instead of simply acknowledging that not all devices have 
the necessary features and resources for web browsing. I have a phone 
that allows me to browse web pages, but I never use that feature because 
the screen's too small. It has IM too, but I don't use that either 
because it takes forever to type in a message.

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

    The whitespace on the Google homepage isn't associated with a
control or any other element on the webpage.

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

    But a design choice to include functionality IS a mistake and needs
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.

    You're not talking about specifying UI. You're talking about
UNspecifying it, after a five years, when most browsers and nearly all
of the browser marketshare is conformant.