[whatwg] LABEL and radio/checkbox onclick

Matthew Thomas wrote:

> On 19 Jul, 2004, at 12:25 PM, Mikko Rantalainen wrote:
>> I'd also suggest that exact focus behavior would be defined for all 
>> cases. For example, see [1] and test case [2]. I'd definately allow 
>> label for any control to be clickable. If some native GUI has low 
>> usability [3],
> 
> If you know of *any* native GUI that works the way you are asking for, 
> you could at least name it.

    So if I hacked a copy of Linux to do this, that would be acceptable? 
Somehow, I doubt this would satisfy you.

> That would be more useful than referring to
> all the GUIs that do not work that way as "some native GUI [which] has 
> low usability". Such feigned ignorance is not credible, since you used 
> one such GUI -- Windows 2000 -- to send your message.

    Let's not pretend everyone uses Windows for the GUI. This is heading 
into a kind of argument no one want to get into...

>> please, let's not limit all *future* browsers and native GUIs because 
>> of that.
> 
> It's not limiting.

    Sure it's limiting. We're talking about prohibiting UA vendors from 
implementing browser UI as they see fit. That's a limitation.

> If the GUI of any future OS changed this behavior, 
> HTML5-supporting browsers for that platform could easily be updated to 
> match. (Internet Explorer and Safari bundling notwithstanding, browsers 
> are still being updated much more frequently than OSes.)

   Not if people stop using label because there's no difference between 
<label> and plain text. Also, without a requirement that the feature be 
included, how do you know the browser behavior won't simply act like the 
same browser does on a different platform? For instance, having 
differing behaviors in Mozilla on various platforms would require 
special code for specific operation systems. Furthermore, if the 
platform isn't the dominant platform like Windows, there will be fewer 
developers to make the OS-specific changes.

> But since all 
> native GUIs have stuck with this behavior for the past 20 years, and 
> changing it would not be a noticable improvement (if indeed an 
> improvement at all), such an event is highly unlikely.

    History is filled with conventions that lasted a long time but don't 
exist anymore. Age does not equal merit.

>> [3] It really doesn't make any sense to have non-functional areas on 
>> GUI. Especially if those areas do logically have 1:1-relation to some 
>> control. So allow those areas to be clickable for better usability.
> 
> Nonsense. Labels are part of the important neutral spaces between and 
> around controls

    Since when? I don't know about you, but I always put neutral spacing 
between the labels and other parts of the UI, if only for aesthetic 
reasons. I never use the labels themselves as a form of spacing.

> (so important that platform vendors specify their exact 
> thickness in interface guidelines).

    I doubt vendors specify the thickness of labels in the interface 
guidelines, but I'm willing to let you prove me wrong, so let's see them.

> These neutral spaces help prevent 
> harm from people clicking on the wrong control by accident

    How do labels to this? Often times, controls are stacked vertically, 
while labels align with the controls horizontally, so the only neutral 
space that separates the controls has nothing to do with the label.

 > (especially if that control is a button).

    Buttons have their own internal labels.

> And in brushed-metal windows in Mac OS X, 
> any neutral space (including most labels) may be dragged to move the 
> window, making for a much larger draggable area than just the title bar. 
> (I'd rather that worked for all windows, but that's getting off-topic.)

    And if they click on the label instead of a visually open space and 
try to drag it, nothing will happen and they'll try again somewhere 
else. (Not to mention the fact that this is not the standard GUI for all 
  Mac applications.)

Received on Thursday, 22 July 2004 07:32:06 UTC