[whatwg] LABEL and radio/checkbox onclick

[Matthew Raymond]

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

> The previous behavior can be recovered quite simply using Javascript  
> (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  
> anyway).

    So the user should have to rely on Javascript, which you acknowledge 
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 
decade?

>> 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  
> controls?

    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  
>> events being fired at the control when Javascript is introduced to  
>> 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 
and resort to simulating its behavior using <span> and Javascript, which 
means there will be no real semantic association between a control and 
its label.

> [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  
>> solution:
>>
>> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004- 
>> August/001764.html
> 
> 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?