- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Thu, 22 Jul 2004 10:09:32 -0400
Matthew Thomas wrote:
> Firstly, this is a mailing list for Web geeks. Such people
> understandably have an unusually high tolerance for inconsistency,
> persistently underestimate the harm caused by user mistakes, and
> persistently overestimate the importance of a Web browser relative to
> other applications people use on the same platform.
>
> Secondly, small problems like this are not the sort of thing people
> (other than whiny usability advocates) complain about -- because they
> don't know who to complain to (Web site author? browser developer? OS
> developer? nephew?), and they may not even realize what caused the
> mistake anyway.
You want the HTML spec changed. That puts the burden of proof for
confusion on you. I have never in my life heard of label focus passing
causing problems, but I accept that I am atypical. The real issue here
is that you are giving me scenarios of gloom and doom that I don't
believe would ever happen in the real world. If you're having so much
trouble coming up with even one person who this has actually happened
to, why should anyone on the mailing list take your hypothetical
situations seriously?
>> Furthermore, all UI was originally never in an OS. You are once
>> again creating a blocking condition that prevents all new UI from
>> being incorporated into a browser before it's a native feature of the
>> OS.
>
> GUIs with hypertext existed 21 years before Web browsers were even
> invented. And if browser vendors were really intending to introduce
> "new UI" by making clicked labels focus elements, why don't they do
> that in their preferences/options dialogs, print dialogs, add bookmark
> dialogs, and so on?
Mozilla does.
> They're doing it in HTML not because they think
> it's good design, but because the HTML spec says they must.
I was unaware you had the ability to read vendors' minds. Thank you
for clearing that up. Otherwise I might have thought that the UA vendors
actually had input into the HTML spec, that they may have wanted it
implemented that way to make clicking the controls easier at higher
screen resolutions, or that they wanted the <label> control to behave
consistently across all <input> types.
>>> Interface guidelines typically warn against only the most common
>>> mistakes made by developers. Very many wrong things are not
>>> expressly forbidden in the guidelines for a platform, because the
>>> platform vendor assumes that developers will not be stupid enough to
>>> try them. A platform vendor must take that approach, because if it
>>> did not, the guidelines would need to be much larger, more
>>> expensive, and harder to use themselves.
>>
>> Hmm, I thought you were actually going to explain what is stupid
>> about label focus passing
>
> It is inconsistent with the native GUI behavior.
No, it is in addition to native GUI behavior.
> I had explained that
> three times previously in this thread, and guessed that I would not
> need to do so again. In retrospect, that was a silly mistake on my part.
It was silly on your part to think a disagreement was settled just
because you voiced your side of the argument.
>> rather than just being sarcastic.
>
> No, I was not being sarcastic in the least.
You were suggesting that developers were "stupid enough to try"
label focus passing and other things that may not be specifically
forbidden by vendor GUI guidelines. Sounds like sarcasm to me.
>> I'm sorry, other than picking apart my trivial choice of the word
>> "look", what was your point?
>
> To respond to your objection. Since UAs try to make their HTML form
> elements look like native ones (even Gecko does that on some
> platforms),
That isn't always the case, and many user agents add behavior to
existing native controls. For instance, Opera adds "Go to Web address
here" to an empty address bar when it is not selected.
> it is a mistake to require HTML form element behavior to be
> different from native form element behavior.
No, it's a mistake to create GUI that contradicts or interferes with
native GUI.
>> 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. How does that disrupt the user experience in any OS?
>
> By breaking people's mental models of how labels work.
What model? People don't even think about them. In most GUIs, they
just sit there. All you're doing is giving the labels something useful
to do.
> I should admit that while thinking this through I realized my design
> for a datepicker
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/
> 001162.html> is bad for the same reason. It would make existing user
> actions (that are reasonably likely, either deliberately or by
> accident) do something markedly different from what they do with a
> native datepicker,
Not all operating systems have a single datepicker. I understand
Windows has several. Furthermore, operating systems may not have a
datepicker flexible enough to do everything described in the WF2
specification.
> so it would break people's mental model of how datepickers work.
I'm not sure a strong mental model of datepickers currently exists
in most people's minds, especially considering all the different ways of
picking dates on the Internet.
> It would be better for the day/month/year menus to be
> invoked from an adjacent menubutton (like the menubutton that is part
> of combo boxes), because that would be a visually obvious *addition* to
> the native datepicker, rather than a hidden change to its behavior.
This brings up an interesting issue. The native GUI sometimes
changes when its found to be inadequate for certain tasks. The
datepicker may be an example of this. Should browsers be singled out as
an application that can't break with the native GUI to create controls
and interfaces that, although not part of the OS UI conventions, may
actually be better than anything the OS has?
>>>> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-ua-ui
>>>
>>> ... Which refers for "more information" to
>>> <http://www.w3.org/TR/WAI-USERAGENT/conformance.html#content-or-ua>,
>>> which says that "everything that is not content" includes "the user
>>> interface focus". Therefore, the user interface focus should observe
>>> operating environment conventions.
>>
>> This is in the context of "user agent features only", and since
>> the feature is defined as part of HTML, it is not a feature specific
>> to the user agent.
>
> <input>, <select>, and <option> are "defined as part of HTML" too. So
> why should a <label> be exempt from conforming to the guidelines, while
> "the control that it passes focus to does have to conform to the
> guidelines listed"?
You are misled by the title "label". On one level, the element
<label> and what we call a "label" in a UI are the same in that they
contain that the user can use to identify what a control is supposed to
contain. That, whoever, is the end of the similarity.
A label in most (if not all) GUIs is nothing more than a text block.
You don't even have to use it to label controls. You could use it to
display a paragraph of text or as a header or anything else you might
use text for in a dialog or window. In HTML, this would be the same as a
simple line of text.
What <label> actually represents is text that you associate as part
of a control. The text is part of the control, just as <legend> is part
of the fieldset. This is similar to what goes on with radio buttons and
checkboxes in the native UI with regard to their "label", in that the
text is part of the control, only <label> doesn't play favorites with
what kind of controls can use this functionality.
What else would <label> do? What else would you use it for? In
XForms, <label> is the required child element of a form control. It's
actually semantically part of the control. The element <label> is not
text next to a control, it is an part of the control.
>>> On all widely-used platforms, it is a 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.
>>
>> Radio buttons and checkboxes are different. In those cases, the
>> "label" is part of the control, and has a direct, preprogrammed
>> association with the control.
>
> If GUI toolkit designers had ever thought it necessary or even
> desirable for the label of a non-checkbox/-radiobutton control to have
> "a direct, preprogrammed association with the control", they could
> easily have done so, just like they did with checkbox/radiobutton
> controls. The various relative layouts of label and control could have
> been specified with one flag, or two at most.
A number of factors have conspired to prevent there being a
consistent convention with regard to labels. One of these is screen
resolution. Only recently have screen resolution gotten big enough to
make it difficult to click on things like text boxes, while checkboxes
and radio buttons where always small targets, even at much lower
resolutions.
Also, GUIs aren't created in a vacuum. They influence each other
heavily. Look down at your Qwerty keyboard. It was originally designed
to place common letter pairs as far apart from each other as possible.
This is totally suboptimal for an electronic keyboard design, and better
keyboard designs exist, including the Dvorak keyboard, but we use Qwerty
because everyone is used to it. Similarly, many GUI conventions survive
not because they are better, but because there is an established set of
tools and a tradition among developers. This is incredibly difficult to
overcome unless you have a totally new development environment with
developers that have never programmed in any other environment, sort of
like, say, web design.
>>> And secondly, as convenient markup so that labels in a form can be
>>> styled consistently.
>>
>> That can be done with <span>,
>
> Which isn't as convenient.
It is if you use a single <div> or <span> it for more than one label.
>>> ([...] using <label> for non-checkbox/-radiobutton form controls
>>> still makes consistent author styling easier.)
>>
>> This is inconsistent. You want labels for one type of control to
>> behave one way, while for other controls it behaves differently, yet
>> you want the user to have no way of visually distinguishing between
>> these two functionally different label types. To me, that sounds like
>> bad UI.
>
> If there is any bad UI in it, it's that native checkbox and radiobutton
> labels are clickable but don't look like it.
Won't get an argument from me. I think that labels should have more
of an indication of their clickability. Windows XP does this a little by
highlighting the checkbox or radio button during label mouseover. I
think this could be taken one step further by changing the label's text
style when you hover the pointer over it.
> My guess is that their
> clickability was added as a quick hack in the early 1980s, once testing
> revealed that the checkboxes and radiobuttons themselves were
> uncomfortably small target areas. The designers should have established
> a different appearance to advertise this different behavior, but they
> didn't. Perhaps they could have used a contiguous groove or ridge
> underlining both the checkmark/dot and the label, with no separate
> border around the checkmark/dot artificially belittling the target area.
The problem there is that you're getting too far away from the way
it looks on paper when you have a checkbox or an oval to fill in. Users
might react negatively to it.
> The next time Microsoft or Apple or Trolltech or Symbian or the GTK+
> developers alter their toolkit's default appearance, that is something
> they could experiment with. In the meantime, for browsers to follow the
> OS behavior people are accustomed to would still be less surprising and
> aggravating than establishing a new behavior.
This feature has been in the spec for nearly five years. What's the
rush to change the behavior? Shouldn't we be seeing negative reaction by
now? If years of Internet use by millions of people have failed to
create any real resistance to this feature, why pull it? I can't even
find a web page against it! (Unless you count the mailing list archive.)
>>> 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. In general, device behaviors should always
>> retain at least a degree of consistency to that users don't have to
>> learn a new system from the ground up every time they get a new device.
>
> The vendors of speech and braille browsers would, I hope, disagree with
> you.
Why would you want inconsistency between your braille desktop and
your braille phone or PDA?
Better question: How does the label focus passing cause problems
with braille? Clearly reading the braille isn't registered as a click,
or otherwise blind people couldn't read buttons, menu items, et cetera.
>>> Simply that if different browsers can have different behavior even
>>> on the same platform, it is unreasonable to expect them to have the
>>> same behavior on different platforms.
>>
>> Different browsers don't necessarily support the same standards.
>> Failure of a specific browser to be standards compliant is not
>> necessarily a good reason to change the standard.
>
> Currently, the de-jure HTML standard behavior for <label>s established
> by the W3C conflicts directly with the de-facto GUI standard behavior
> for labels established by Apple and Microsoft. If UAs are to be
> compliant with both standards, one of the standards must change.
Programs on many platforms add behavior to existing native UI to
make it more useful. Why should HTML be any different, especially when
failure to click a label has no adverse effect, and directly clicking on
one is in all likelihood intentional?
> The former standard has been used sporadically by developers for 7
> years; the latter has been used heavily by developers for 20 years.
The Qwerty keyboard has been around for 122 years.
> The
> former is implemented inconsistently in browsers with noticable market
> share;
Only for implicit association, and that's only a problem in IE on my
system. For explicit association, every HTML4 browser I have supports it.
> the latter is implemented consistently in GUIs with noticable
> market share.
If you mean consistently in that an inconsistent system is
implemented consistently, then yes.
> A uniform change of the former would involve updating
> your browser;
Difficult to do for the browser with the largest market share: IE.
> a uniform change of the latter would involve updating
> your browser, and almost every other graphical application on your
> computer, and the operating system itself.
Why bother changing the latter?
> So it's pretty obvious to me
> which should be changed.
Why change at all? Anyone who wants to use either label type on
either the browser or the native UI can do so with trivial effort, and
there's nothing to be gained by removing it from browsers.
>> Furthermore, many browsers do obey HTML specs regarding label focus
>> passing, so are you suggesting that these vendors should have to
>> remove this support in order to be WF2 compliant?
>
> Probably not ("should" rather than "must" would be used for something
> that cannot be changed in Internet Explorer). But that would be moot,
> since browsers would need to follow OS behavior to be WAI-UAAG
> compliant anyway.
I'm not convinced it is non-compliant, since the HTML spec defines
<label> as effectively part of the control it is associated with.
Personally, I find it a bit disturbing that the W3C is trying to
impose a strict set of rules regarding conforming to native GUI
conventions. This wouldn't be tolerated for other software. For
instance, Microsoft Office programs have many features that aren't part
of the native GUI, like menubars that can actually undock from the
window and become floating controls. Do you honestly think Microsoft and
others would tolerate standards bodies telling them they can't do that?
Why should browsers be different, especially considering how difficult
it is to survive in that market?
>>> 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 native behavior of the platform on which the UA runs.
There is an absence of behavior on every platform on which the UA runs.
>> So, effectively, you're combining an unlikely nervous behavior
>
> No, from my years of watching Internet users I'd say it's quite common.
Then at least produce a note from someone describing the trouble
they've had with it.
>> with the unlikely event that the user will click specifically on a
>> label by accident
>
> No, that and the "unlikely nervous behavior" are one and the same
> event. By artificially dividing it you're making it sound less likely
> than it is.
At best, clicking the label as part of nervously clicking about the
web page can only be AS LIKELY and just nervously clicking the page, and
the nervous clicking scenario was the only example you gave me.
>> Recall also that labels are "apparently neutral" because that is the
>> default style in many browsers, not because it is in the specification.
>
> Certainly, UAs could visually explain <label>'s non-native focusing
> behavior by making it look clickable -- applying the same default style
> to <label> as they do to <button>.
Which I fully support.
> But I think both authors and users
> would find the clutter of that appearance considerably more annoying
> than the annoyance (if any) suffered from HTML <label>s having focus
> behavior consistent with native labels.
That would depend no how the styling was done.
Received on Thursday, 22 July 2004 07:09:32 UTC