[whatwg] LABEL and radio/checkbox onclick
Matthew Raymond
mattraymond at earthlink.net
Thu Jul 22 07:32:06 PDT 2004
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.)
More information about the whatwg
mailing list