[whatwg] LABEL and radio/checkbox onclick

[James Graham]

On 18 Aug 2004, at 14:16, Matthew Raymond wrote:

> Ian Hickson wrote:
>> Hmm, yes. This is platform-dependent, though. Added:
>>   <p>The <code>label</code> element's exact default behaviour must
>>   match the platform's label behaviour. For example. on platforms
>>   where clicking a checkbox label checks the checkbox, clicking a
>>   <code>label</code> element must cause a <code>click</code> event to
>>   be synthesised and fired at the checkbox.</p>

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.

>
>    There are a few problems with this:
>
> 1) When HTML 4.01 markup is transferred to a WF2 document, the <label>  
> behavior changes for the same markup with absolutely NO WAY TO RECOVER  
> THE PREVIOUS BEHAVIOR.

Are the capitals really necessary?

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).

>
> 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. 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? I can't imagine this is a serious problem given that other  
controls already have UA-specific behavior.

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

[I haven't had time to understand what the <object> point was about so  
I've skipped it]

>    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. I totally fail to see why this is such an  
important issue that custom CSS properties are necessary.