Re: [whatwg] Form controls inside a label but not labelled by it
On Sun, 15 Jan 2012, Mounir Lamouri wrote: > > I agree that Opera/IE behavior is better to solve this case but it > doesn't help for this one: > 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. I don't really understand why you'd use for that case. There's no label, just two controls. All in all I'm not at all convinced this is something we should encourage. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form controls inside a label but not labelled by it
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: 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: 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
Re: [whatwg] Form controls inside a label but not labelled by it
On Fri, 10 Jun 2011, Mounir Lamouri wrote: > On 06/04/2011 12:57 AM, Ian Hickson wrote: > > On Thu, 17 Feb 2011, Mounir Lamouri wrote: > > > According to a comment of Hixie in [1], this case has been handled by > > > the specs in 2004 but it doesn't seem to be any more and UA's have a > > > very different behaviour here: > > > - Firefox: focus and activate the labelled element ; > > > - Webkit: focus the form control and activate the labelled element ; > > > - Presto and IE9 RC: focus the form control (doesn't activate the > > > labelled element). > > > > > > I think Webkit's behaviour makes the more sense here and it would be > > > nice to have it specified. > > > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 > > > > Oops, not sure why the text was lost in the WF2 merge. > > > > 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: Why would you want inputs "b" and "c" to be unfocusable via the mouse? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form controls inside a label but not labelled by it
On 06/04/2011 12:57 AM, Ian Hickson wrote: On Thu, 17 Feb 2011, Mounir Lamouri wrote: According to a comment of Hixie in [1], this case has been handled by the specs in 2004 but it doesn't seem to be any more and UA's have a very different behaviour here: - Firefox: focus and activate the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Oops, not sure why the text was lost in the WF2 merge. 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. Authors can emulate the WebKit behaviour if they really want it by just calling .click() on the element they want to have activated when the target is focused. Sure. Like the the Firefox one ;) -- Mounir
Re: [whatwg] Form controls inside a label but not labelled by it
On Sun, Jun 5, 2011 at 3:27 PM, Aryeh Gregor wrote: > Things like radio buttons and checkboxes are small, and hard targets > to hit with a mouse. It's much nicer to be able to be able to click > anywhere in the whole label. It requires less effort. Oops, I misunderstood the case we were talking about. Disregard this.
Re: [whatwg] Form controls inside a label but not labelled by it
On Fri, Jun 3, 2011 at 6:57 PM, 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? > > Authors can emulate the WebKit behaviour if they really want it by just > calling .click() on the element they want to have activated when the > target is focused. Things like radio buttons and checkboxes are small, and hard targets to hit with a mouse. It's much nicer to be able to be able to click anywhere in the whole label. It requires less effort.
Re: [whatwg] Form controls inside a label but not labelled by it
On Thu, 17 Feb 2011, Mounir Lamouri wrote: > > Mozilla has an old Gecko bug [1] lying around about form controls not > focusable when they are inside a label that is not labelling them: when > the user clicks the form control, because it's part of the label, the > activation behaviour is done on the labelled element. Thus, the form > control isn't focused. Recently, this bug appeared on GMail [2]: if you > try to set a signature with Firefox and the HTML5 parser enabled, you > will not be able to focus the textarea but you will focus the radio > button instead. You can see a minimized test case here: > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/839 > > According to a comment of Hixie in [1], this case has been handled by > the specs in 2004 but it doesn't seem to be any more and UA's have a > very different behaviour here: > - Firefox: focus and activate the labelled element ; > - Webkit: focus the form control and activate the labelled element ; > - Presto and IE9 RC: focus the form control (doesn't activate the > labelled element). > > I think Webkit's behaviour makes the more sense here and it would be > nice to have it specified. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Oops, not sure why the text was lost in the WF2 merge. I've added equivalent text back. It describes the Opera/IE behaviour; could you elaborate on why the WebKit behaviour is better? Authors can emulate the WebKit behaviour if they really want it by just calling .click() on the element they want to have activated when the target is focused. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form controls inside a label but not labelled by it
On 2/17/2011 10:23 AM, Boris Zbarsky wrote:
> On 2/17/11 8:37 AM, Matthew Raymond wrote:
>>
>>
>>
>>
>>
>> The label doesn't specify which control is the one it's labeling.
>
> But the spec does:
>
>If the for attribute is not specified, but the label element has a
>labelable form-associated element descendant, then the first such
>descendant in tree order is the label element's labeled control.
>
> Now the markup here is invalid per the spec ('s content model
> says "no descendant labelable form-associated elements unless it is the
> element's labeled control"), but which control is labeled is quite
> well-defined.
I just realized that this is irrelevant because of this part of the spec:
The label element's exact default presentation and behavior, in
particular what its activation behavior might be, if anything,
should match the platform's label behavior.
That means that if clicking a text area wouldn't normally /focus/ an
option button on a particular platform (which, I believe, is all of
them), it shouldn't focus the option button. That means the Mozilla
behavior is definitely invalid.
> We all agree it's crappy markup.
>
> People do this all the time.
Never said they didn't. I'm just pointing out that an author has no
reason to believe that a specific behavior will occur based on the
semantics of the markup.
Re: [whatwg] Form controls inside a label but not labelled by it
On 2/17/11 8:15 AM, Anne van Kesteren wrote: If you nest elements with activation behavior only the innermost is activated. doesn't have activation behavior. So if I have: and I click the textarea, then the will be activated unless we add some sort of special-case for this. You can also test this by e.g. nesting elements and see which link is followed. has activation behavior (if it has an href and so forth). So the situation is totally different. -Boris
Re: [whatwg] Form controls inside a label but not labelled by it
On 2/17/11 8:37 AM, Matthew Raymond wrote:
The label doesn't specify which control is the one it's labeling.
But the spec does:
If the for attribute is not specified, but the label element has a
labelable form-associated element descendant, then the first such
descendant in tree order is the label element's labeled control.
Now the markup here is invalid per the spec ('s content model
says "no descendant labelable form-associated elements unless it is the
element's labeled control"), but which control is labeled is quite
well-defined.
In fact, the author is attempting to use it as a double label for two
controls, so semantically it would seem like there is an attempt to
focus both controls simultaneously. Worse, there's no actual content in
the label besides controls and whitespace.
We all agree it's crappy markup.
People do this all the time.
-Boris
Re: [whatwg] Form controls inside a label but not labelled by it
On 2/17/2011 7:10 AM, Mounir Lamouri wrote: > According to a comment of Hixie in [1], this case has been handled by > the specs in 2004 but it doesn't seem to be any more and UA's have a > very different behaviour here: > - Firefox: focus and activate the labelled element ; > - Webkit: focus the form control and activate the labelled element ; > - Presto and IE9 RC: focus the form control (doesn't activate the > labelled element). > > I think Webkit's behaviour makes the more sense here and it would be > nice to have it specified. Let's take a look at a snippet of the markup: The label doesn't specify which control is the one it's labeling. In fact, the author is attempting to use it as a double label for two controls, so semantically it would seem like there is an attempt to focus both controls simultaneously. Worse, there's no actual content in the label besides controls and whitespace. On 2/17/2011 8:15 AM, Anne van Kesteren wrote: > The spec defines the Opera/IE behavior which I think is actually > better. > If you nest elements with activation behavior only the innermost is > activated. You can also test this by e.g. nesting elements and > see which link is followed. I agree. If you assume that a can label only one control at a time, then the one above can label either the or the , but not both. The Webkit behavior is functionally convenient, but semantically it's nonsense, and it could be triggered just by someone accidently placing the closing tag in the wrong place. However, that does leave us in a situation where we have to use Javascript to achieve the Webkit behavior. Is there a semantic way to do this at all?
Re: [whatwg] Form controls inside a label but not labelled by it
On Thu, 17 Feb 2011 13:10:09 +0100, Mounir Lamouri wrote: According to a comment of Hixie in [1], this case has been handled by the specs in 2004 but it doesn't seem to be any more and UA's have a very different behaviour here: - Firefox: focus and activate the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. The spec defines the Opera/IE behavior which I think is actually better. If you nest elements with activation behavior only the innermost is activated. You can also test this by e.g. nesting elements and see which link is followed. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Form controls inside a label but not labelled by it
Hi, Mozilla has an old Gecko bug [1] lying around about form controls not focusable when they are inside a label that is not labelling them: when the user clicks the form control, because it's part of the label, the activation behaviour is done on the labelled element. Thus, the form control isn't focused. Recently, this bug appeared on GMail [2]: if you try to set a signature with Firefox and the HTML5 parser enabled, you will not be able to focus the textarea but you will focus the radio button instead. You can see a minimized test case here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/839 According to a comment of Hixie in [1], this case has been handled by the specs in 2004 but it doesn't seem to be any more and UA's have a very different behaviour here: - Firefox: focus and activate the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Thanks, -- Mounir
