[whatwg] Form controls inside a label but not labelled by it

[Mounir Lamouri]

On 01/10/2012 11:24 PM, Ian Hickson wrote:
> On Fri, 10 Jun 2011, Mounir Lamouri wrote:
>> On 06/04/2011 12:57 AM, Ian Hickson wrote:
>>> I've added equivalent text back. It describes the Opera/IE behaviour;
>>> could you elaborate on why the WebKit behaviour is better?
>>
>> Webkit behavior makes more sense because it tries to combine expected behavior
>> for clicking inside a label and for clicking on an interactive element. It
>> sounds much more natural.
>> Opera/IE behavior is similar to ignoring the fact that the interactive element
>> is inside a label. Basically, Opera and IE are assuming that the author didn't
>> want to write what he/she wrote. I do not think that is a sane behavior when
>> they are good and real use cases for it.
>
> Well, the _spec_ assumes that the author didn't want to write what they
> wrote. That's why it's non-conforming!
>
> I don't think it makes sense to try to activate two things at once. The
> author clearly didn't express what they meant to express, but it seems
> highly unlikely that the author meant to express that the control in
> question should not be focusable at all.
>
> I would guess that this error occurs typically due to copy pasta:
>
>     <label for=a>  <input id=a>  </label>
>     <label for=a>  <input id=b>  </label>
>     <label for=a>  <input id=c>  </label>
>
> Why would you want inputs "b" and "c" to be unfocusable via the mouse?

I agree that Opera/IE behavior is better to solve this case but it 
doesn't help for this one:
<label><input type='radio'><input></label>
And it seems that web authors tend to write that and expect the radio to 
be checked when the text field is focused based on the bug reports we had.

Between two use cases I think the second is more important because the 
authors are more likely to have write something they meant to write.

--
Mounir