[whatwg] LABEL and radio/checkbox onclick

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". If the web developer wants one of theses blocks
of text, a simple <span> is capable if giving the developer everything
he/she needs.

>>>>    You're not talking about specifying UI. You're talking about 
>>>> UNspecifying it, after a five years, when most browsers and nearly 
>>>> all of the browser marketshare is conformant.
>>>
>>>
>>> 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.

> 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 saying you're making this up,
but I'm also not saying you're making a rational argument here.

> (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. Why not simply give the user the option of what UI
behavior the want to use? That way, if something confuses or annoys
them, they can simply turn it off rather than denying the functionality
to the entire populous.

>> 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.

    There are two problems with this conclusion. One is that one has to
be negligent not to see all possibly beneficial features for an OS.
That's the equivalent of suggesting its a personal failure of the OS
experts every time someone invents a new useful feature for an OS.

    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.

> More importantly, you have failed to justify a markup language spec 
> specifying the behavior of platform-specific widgets.

    Actually, I've argued several times that <label> is actually a new
kind of widget not supported on many operating systems. Furthermore,
because of the issue of backwards compatibility with HTML 4.01 compliant
content and UAs, I shouldn't have to justify it. On the contrary, you
should have to justify its removal, especially considering the fact that
its removal will affect the functionality of legacy content.

    I should also point out that in order to support the changes you
want in the WF2 emulation layer, code would have to be written to
DISABLE focus passing, and that if this layer ends up being
cross-platform, the emulation layer would also have to detect whether or
not the platform supports label focus passing. I strongly suspect that
nobody actually wants to write such code, so I doubt your changes will
be put into the WF2 specification.

> 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.

> 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. It's just not going to
happen. There will always be some operating system left unrepresented,
just as there are browsers that are not represented by individuals in
this mailing list. All we can really do is look at known or obvious
cases, find potential problems and resolve them in a way that causes the
fewest amount of problems for all parties involved.

>>> 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.
 From what I've read on the SDL forums, I know that there are some
programmers that absolutely hate double-clicking, so I wouldn't be
surprised if there were several operating systems that don't have it.

> 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.

    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.

Received on Friday, 6 August 2004 20:08:03 UTC