[whatwg] LABEL and radio/checkbox onclick
jg307 at cam.ac.uk
Mon Aug 9 14:58:36 PDT 2004
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.
>> 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
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
>>> 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.
> 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
> 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).
> 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"
More information about the whatwg