[whatwg] LABEL and radio/checkbox onclick
mpt at myrealbox.com
Tue Jul 20 03:03:38 PDT 2004
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  and test case . I'd definately allow
> label for any control to be clickable. If some native GUI has low
> usability ,
If you know of *any* native GUI that works the way you are asking for,
you could at least name it. 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.
> please, let's not limit all *future* browsers and native GUIs because
> of that.
It's not limiting. 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.) 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.
> Perhaps add a note explaining that some native GUIs do not support
> that feature and some user agents may opt for bug-compliant behavior.
Since (1) the spec editor (once he gets to the grandparent of this
message, if not before) knows that "some native GUIs" is really "all
native GUIs", (2) their behavior in this regard has been consistent for
the past 20 years, and (3) none of the GUI vendors are known to
consider that behavior a "bug" or any alternative behavior a "feature",
such a note would be a lie. It is probably a bad idea for any part of a
spec to contain lies; it seems likely to breed disrespect for the spec
as a whole.
>  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 (so important that platform vendors specify their exact
thickness in interface guidelines). These neutral spaces help prevent
harm from people clicking on the wrong control by accident (especially
if that control is a button). 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
More information about the whatwg