- From: James Graham <jg307@cam.ac.uk>
- Date: Mon, 09 Aug 2004 22:58:36 +0100
of Matthew Raymond wrote: > James Graham wrote: > >> Matthew Raymond wrote: >> >>> Chris Kaminski wrote: >>> >>>> And how many users know what a browser is? >>> >>> >>> They don't have to. The just need to know what the window that had >>> the "Internet" in it looks like. My sister refuses to use Mozilla >>> Firefox on the house computer because it's "different" from Internet >>> Explorer. Similarly, people know what their browser looks like, even >>> if they don't know what it is. >> >> >> They do have to because many programs that aren't IE use IE to render >> parts of their interface (there are also programs that embed Mozilla >> and programs on Mac OS that use Webcore). "Is this program IE?" isn't >> a suffcient test for "will this program use HTML or native behavior". > > > Good point, although it ignores the fact that he said "browser" and > not "HTML rendering engine". The ability to display HTML doe not > necessarily make a program a browser. > > Increasingly, HTML will be used for common apps on systems that > don't require high performance UIs. So consistency with the rest of the > OS is a factor. It should be noted, however, that most operating systems > don't have a label widget, they have text blocks that are, in some > cases, called "labels". That's irrelevant to a discussion about UI - the user has no idea of what's implementable in different frameworks, they only know what happens when they interact with the computer. > If the web developer wants one of theses blocks > of text, a simple <span> is capable if giving the developer everything > he/she needs. Well, except the association between label and control that is so important to any type of assistive technology. This is *really* important, even for a visual UA (since the HTML spec recommends that accesskeys are defined on labels rather than controls and it's important to know which label/control an accesskey applies to). Using <span> in place of <label> is tag abuse at least as bad as using <table> to provide formatting. >>>> lack of functionality is a design decision just as is functionality. >>>> Just as in an image, negative space has visual weight the same as >>>> positive space. Two sides, same coin. >>> >>> >>> Hardly. [...] Lack of functionality MIGHT be a choice, or it may >>> simply be an oversight. >> >> >> So you admit that the word "hardly" is essentially just hyperbole. > > > I admit only that the lack of functionality cannot be assumed to be > an intentional exclusion of such functionality. Nor can it be assumed to be an oversight. In either case, the user doesn't care, she just requires her computer to be as intuitive to operate as possible, and that means the interface in different programs must be consistent. >> It's >> very clear that lack of a particular behavior, even one that some >> users find useful, is often a design choice; > > > How often? Which behaviors? I'm not sure that's relevant. It's certainly not clear how one could collect such numbers. >> (lack of) focus follows mouse is an obvious example. > > > In some operating systems, this is a feature that can be turned on. > In others, there may be utilities that allow you to have this > functionality. However very few widely used window managers turn this on by default, presumably because users find it difficult. That's an example of a lack of behavior being a design choice, something that you seem to believe is impossible. >>> Functionality shouldn't be forbidden simply because the OS developers >>> didn't think to put it into the operating system. >> >> >> You have provided no evidence that this particular example is actually >> a case of the human / computer interaction experts being negligient >> rather than their making a valid design choice. In the case of focus and control labels, the evidence that people thought about this is that specific controls do allow focus passing. It's not conclusive but it's there. In any case, the specific case isn't so important as the principle that we shouldn't try to specify the details of UI which would otherwise depend on the UA and platform. > The second problem is that, in this case, you're requiring anyone > who works on an HTML specification to know the motivations behind the OS > conventions of every operating system in the Known Universe, plus > predict the UI features of operating systems that don't even exist yet. No, you're requiring that. I'm requiring that the spec doesn't require a specific UI behavior so that UAs may follow platform specific conventions and requirements. > >> More importantly, you have failed to justify a markup language spec >> specifying the behavior of platform-specific widgets. > > > Furthermore, > because of the issue of backwards compatibility with HTML 4.01 compliant > content and UAs, I shouldn't have to justify it. I believe that a WF 2 compliant UA should be allowed to implement any behavior for <label> it sees fit. Some vendors may consider HTML 4 compliance to be more important than platform conventions, others may value the user experience over spec compliance. Neither choice should be required. > On the contrary, you > should have to justify its removal, It specifies something (widget behavior) that is the domain of the UA. It prevents UAs from implementing widgets tat behave like native apps on many platforms, thereby making the user experience offered by HTML forms worse than it would be if this behavior was not specified. > especially considering the fact that > its removal will affect the functionality of legacy content. How so? If this is true, UA vendors will probably opt for backward compatibility but that doesn't mean we should continue to require the old behavior since it violates the general principle that the details of widget and their behavior are UA specific. >> If designers want to force a particular behavior they can do so using >> script (perhaps wrapped up in Web Controls objects). > > > Not if the user agent has Javascript disabled, and furthermore, this > won't solve the problem of legacy content no longer functioning as > specified in the previous HTML spec. Lots of things don't function the way that the HTML 4 spec suggests they should. If the WF2 spec states that there is no particular requirement for the focus behavior when labels are clicked, UA vendors will be able to do whatever they like, including retaining the old behavior. WF2 pages that rely on this behavior will, however, be considered broken just like those that rely on some other UA-specific quirk are broken. > >> Otherwise we have no business "innovating" GUIs without regard for the >> diversity of avaliable platforms and the standard behavior on each. > > > You can't expect people writing a web specification to have > knowledge of every existing operating system. That's my point. That is exactly why nothing should be specified. Because there is no possible way for us to determine the behavior that makes most sense in all UAs. I don't quite understand where you've got the idea that leaving these details to the UA makes it less likely that WF will make sense on new or uncommon platforms. I think it's very likely to make it work better since vendors do have the knowledge of the specific OS they are targeting that we lack. >>>> Other than that, though, I'm not seeing any big deal either way. >>> >>> >>> To me, it represents a larger case. If we try to add features to >>> web app markup that aren't in the OS, no matter how beneficial they >>> may be, will they be removed from the draft to serve OS conventions? >> >> >> What sort of features do you have in mind? If these "features" mean >> redefining the behavior of platform-specific widgets for no particular >> reason then, yes, I would hope they are removed. > > > Then you would agree to, for instance, removing support for > |ondblclick| from operating systems that don't support double-clicking. How does an ondoubleclick event redefine any platform specific behaviors? It adds functionality and therefore I support it On the other hand, I disapprove of programmers abusing the event to alter widget behavior, but the platform HIG documents deal with that, not the markup/DOM specifications. I also disagree with programmers who create pages requiring these events to exist in order that the page to functions that doesn't mean the events themselves are inherently bad. It's true that ondblclick doesn't make sense on OSs that don't have double clicks. In that case, I would expect that either any events defined in an ondblclick handler would be ignored (much like we have device specific CSS properties which are ignored by devices that don't support them) or it would be mapped to an event on that device which performs a similar role as double click on devices which do support it (e.g. apple + click on a one button mouse is equivalent to right click on a multibutton mouse when using a Mac. Therefore, on that platform, it makes sense that the two actions generate the same events. In practice they might not, I don't know). >> If they're really new >> features, it's hard to see how they can conflict with existing OS >> conventions or behaviors. > > > In Windows, clicking an icon the first time selects it. Clicking it > a second time (but not double-clicking it) allows you to change the > label. (And clicking the icon label in Windows passes focus, BTW.) If > double-click didn't exist, you'd be renaming the icon. Now that's just > in Windows. Think of all the possible behavioral differences possible in > all the various operating systems, including handhelds. So you're saying that programmers who have to write their own DHTML widgets won't always be able to follow platform specific behaviors and using that to justify having WF2 widgets have unusual behaviors? That doesn't make sense; one of the major benefits of having predefined widgets is that they can be rendered in a way appropriate to the UA being used. If the UA authors care about usability, that includes following the platform guidelines. We certainly shouldn't try to specify away such advantages. (Slightly offtopic; DHTML widgets are a disaster for accessibility because the UA has no way of presenting an interface that makes sense on that platform) . > Remember, every feature is a new feature at some point, and if even > the lack of functionality can be considered a feature, than any new > feature can potentially conflict with an existing OS "feature". In that > regard, holding user agents to "a foolish consistency" with the OS > limits UI innovation and prevents popular widgets that may no exist in > the OS from being introduced on the web. If there is some widget needed for WF2 that does not exist on the OS, it is up to the UA vendor to find an implementation that makes as much sense as possible on the platform they are targeting. I don't see how that limits our ability to innovate. If we come up with some remarkable piece of new functionality it would certainly be good for the spec to provide an example of a possible interface but it shouldn't be normative. -- "If anybody ever tells you that you?re using the language incorrectly, just yell 'prescriptive grammarian!' at the top of your voice and all the linguists in the building will run over and surround the guy... and then they?ll rough him up"
Received on Monday, 9 August 2004 14:58:36 UTC