- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 20 Jul 2004 11:28:18 -0400
Matthew Thomas wrote: >> I presume that "wrong" means it's not commonly done in the native UI. > > In this case it means it's *never* done in the native UI. So doing it > would be surprising-and-not-in-a-good-way. The only thing about it that surprised me was that clicking on the label did anything at all for textboxes and text areas, and that was because I'd never clicked them. I hear a lot about how people will get confused and accidently perform some action that is catastrophic, but I'm not hearing a lot of people saying that actually happened to them. I'd also like to point out that the function of labels can be more clearly indicated using CSS. For instance, with implicitly associated controls, you can have the label text and the control border change to the same color when you put your mouse over them. 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. > 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 rather than just being sarcastic. >> 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? >> 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. How does that disrupt the user experience in any OS? >>> 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 > > > ... 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. > 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. This is much closer to what a <label> element really is. It's text that has a direct association with the control. The label element is, therefore, not the same as the text blocks used in some native UI and should not be treated as such. >> ... >> 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? > And > secondly, as convenient markup so that labels in a form can be styled > consistently. That can be done with <span>, and in many cases labels aren't styled at all. > ([...] 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. I would like to point out that when I was first becoming accustom to Windows, I was unaware that clicking on the label for a checkbox or radio button was the same as clicking on the control directly. >>> 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. 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. >>>> 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? > > 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. 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? > 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? >> Why would you be hitting enter while randomly clicking on places on >> the form? > > I did not say "while typing Enter", I said "shortly before typing > Enter". For example, someone may be absent-mindedly tapping at the > (apparently neutral) area of the "To:", "CC:", and "BCC:" labels in a > Webmail app while he tries to decide whether to add anything further to > the message. He remembers something else he must write about, so he > presses Enter to start a new paragraph. If <label> behaves like it does > native apps, nothing happens -- the textarea has lost focus, and no form > element is focused, so nothing happens until he realizes his mistake. > But if <label> behaved the way you wanted it to, one of the address > entry fields would be focused, and since those are single-line text > fields, pressing Enter would send the message prematurely. So he was previously typing a message in a text area when he moves his hand from the keyboard to the mouse and suddenly starts clicking on random places in the web page without realizing that this will take focus away from the text area. Then he hits enter for a new line without seeing where the text cursor is, or the fact that it's no longer there, since the text area has lost focus. So, effectively, you're combining an unlikely nervous behavior with the unlikely event that the user will click specifically on a label by accident while at the same time not being aware of at least one existing OS behavior and one browser behavior. Recall also that labels are "apparently neutral" because that is the default style in many browsers, not because it is in the specification.
Received on Tuesday, 20 July 2004 08:28:18 UTC