James Graham wrote:
> The point:
> 1) It confuses users.
Who's to say it doesn't confuse users when clicking on the label for
a radio button or check box affects the control, but for a text box it
doesn't? Wouldn't the consistency of clicking all labels to focus the
control be LESS confusing?
> 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!
> 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.
What's there to learn? If they don't know to click on it, they just
won't.
> 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.
As for browsers, the only control that comes close to what you
describe is the address bar, which is such a large target, most people
won't go for the label anyway. (Note that on my Windows XP machine,
neither Mozilla nor Opera even have labels for the text entry controls
in the toolbars.) Interestingly enough, the Mozilla UI obeys the same
label focus passing convention that's in HTML.
> 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.
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?
The bottom line is that labels label controls. As a result, they
contain no information beyond the association with the control.
Therefore, the only reason to focus the labels themselves is to either
read them or copy their text.
> Can you demonstrate that:
> 1) This UI is functionless on all web-capable devices and will remain so
> in the future?
If you mean for existing native applications, yes, because in most
cases there is no association between the text and the control other
than their proximity to each other. Only reimplementation of labels
using something completely new would have any possibility of causing a
problem. So we're talking about an OS in the future deliberately
implementing a new UI widget for replacing existing labels that directly
conflicts with the label UI in most browsers.
> 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).
First of all, it has been suggested that the way Enter is handled
needs to be addressed instead of the label issue, which I agree with,
since the use of Enter in form submission is not consistent across all
browsers. In many cases, you don't what the user to be able to submit a
form with the Enter key at all (such as when you have many textboxes to
enter information into).
Also, it has never been explained to my satisfaction how such an
accidental submission would realistically happen. Harmful side effects
are minimal and improbable to the point of absurdity.
>>> 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/.
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.
> 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.
>>> 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?
>>> 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
There are actually people who advocate this. (Not that I do...)
> - it's not convenient or useful.
It hardly inconvenient. All you're talking about is an extra class
attribute and some CSS that you were going to use for <label> anyway.
Anyone who knows anything about CSS can do it.
As for useful, what makes <label> so much more useful from a styling
standpoint? I could wrap controls and text in a single a <span> or
<div>, thus styling all the text next to the controls without using
multiple elements. With <label> only a single control can be contained
inside, forcing you to use a <label> element for every text label. The
point of <label> is not styling, it's to semantically and functionally
associate the label with the 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 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.
> 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.