[whatwg] LABEL and radio/checkbox onclick

[James Graham]

Matthew Raymond wrote:
> Chris Kaminski wrote:
> 
>>> But users do have a way of knowing when labels exhibit the HMTL 4.01 
>>> specified behavior. It happens only in browsers.
>>
>>
>> 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".

>>>    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. It's 
very clear that lack of a particular behavior, even one that some users 
find useful, is often a design choice; (lack of) focus follows mouse is 
an obvious example.

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

More importantly, you have failed to justify a markup language spec 
specifying the behavior of platform-specific widgets. If designers want 
to force a particular behavior they can do so using script (perhaps 
wrapped up in Web Controls objects). Otherwise we have no business 
"innovating" GUIs without regard for the diversity of avaliable 
platforms and the standard behavior on each.

>> 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. If they're really new 
features, it's hard to see how they can conflict with existing OS 
conventions or behaviors.

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