[whatwg] LABEL and radio/checkbox onclick
mattraymond at earthlink.net
Wed Aug 18 19:08:16 PDT 2004
James Graham wrote:
> Ian: does the spec make it clear that the HTML 4 behavior is expected
> when a <label> is focused by use of an accesskey (i.e. in this case
> focus should pass to the control?). Not doing this is a serious
> usability problem since HTML 4 suggests defining the accesskey on the
> label rather than the control and there is no platform-dependent
> behavior to match in this case.
The original idea was that the access key focused the <label>, which
then passed focus to the associated control. I think that's virtually
what it says in the HTML 4.01 specification. As a result, if focus isn't
necessarily passed to the control anymore, logically the access key
should only focus the text (if the native platform allows such behavior).
Obviously, that won't work, so what we're really talking about is
having |accesskey| behave in a way that's inconsistent with whether
focus passing is allowed: |accesskey| has to work in all cases. This has
to be the case for compatibility reasons no matter what you do with the
> (obviously this won't work in all cases but is acceptable in most cases
> since most pages that rely on specific behavior also rely on scripts
is not always an option, because they dared to rely on a specific
behavior specified in an HTML web standard that's been around for half a
>> 2) The webmaster cannot reliably predict the behavior of <label> on a
>> platform without extensive knowledge of that platform. Therefore, if
>> the webmaster is targeting a specific set of operating systems and
>> browsers, he must have knowledge of how the native UI handles labels
>> for each control he uses, rather than simply depending on the HTML
>> 4.01 specified behavior.
> I don't understand why this would ever be so important that a change in
> behavior would break a page.
Why is changing the existing specified behavior so much more important?
> Can you provide a real world example where
> the functionality of a page is broken (e.g. making it impossible to
> submit the form) when labels do not pass click events to their
With regard to making it impossible to submit, the reverse certainly
isn't true (since allowing focus passing in valid markup causes no such
problems), so I fail to see why I should have to prove such a thing.
Besides, if every revision we make to HTML has to break a form to rise
to the level of being a bad idea, nothing will ever be left out of the
spec. Notice that my CSS suggestion doesn't meet that criterion.
As for examples where event passing is needed, how about textboxes
where the user enters three characters or less? At a high resolution, it
can be exceedingly difficult to select a target that small.
>> 3) You're providing no method of detecting whether input is passed to
>> the associated control. Therefore, is there not a risk of multiple
>> make up for the lack of event passing on some platforms?
> There is always the possibility that poor scripts will cause problems.
And what, in this case, would be an example of good scripting? If we
make event passing inconsistent across different kinds of controls on
different platforms, a webmaster may just avoid using <label> entirely
means there will be no real semantic association between a control and
> [I haven't had time to understand what the <object> point was about so
> I've skipped it]
The <object> element is a control. A <label> can be associated with
the control. Under the proposed change to <label>'s behavior, <label>
must only pass events to an associated control if that behavior is
correct for the native platform. However, since <object> could be any
kind of control, there's no way of knowing the behavior that is
appropriate for the specific <object>. Therefore, the proposed spec
change isn't practical to implement with regard to <object>.
>> Please see the following message for what I believe to be a better
> That would destroy consistency between pages as well as between
> different applications.
How so? Under the opposing specification, in order for a browser to
remain compliant with HTML 4.01 AND "HTML5", it would have to identify
the document type and use the corresponding behavior. The same markup,
copied from one document type to another, would behave differently.
Furthermore, the change to spec makes <label> behave differently on the
same platform based on a single attribute of a separate element, without
any indication of that in the markup itself. Explain to me how any of
that is consistent?
My system, by contrast, is all about consistency. By setting
input-redirect, you consistently get the same behavior for a specific
control for both HTML4 and HTML5 markup. The default CSS values ensure
compliance with the default behavior for markup in HTML4 and HTML5 as
they are currently written. If a webmaster needs a certain behavior for
a specific control, he can set input-redirect and not have to worry. The
only real issue here is that the webmasters get to decide where the
consistency lies rather than the spec writers or the OS developers.
> I totally fail to see why this is such an
> important issue that custom CSS properties are necessary.
Yet you think it's so important that you think the behavior needs to
be changed in a way that is not behaviorally backwards compatible with
HTML 4.01, especially when all HTML4-compliant browsers already support it?
More information about the whatwg