mass-moved component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The sentence is question is required to make sure that if you click on a text field inside a <label> whose labeled control is another text field, you don't end up focusing the other text field (which would be rather confusing to users).

(The sentence in question was added in r6187.)

The text is still there, and is still confusing.  In the example, the following markup is used
<label><input type=checkbox name=lost> Lost</label>

The <input> is a child of the <label>.  The text in the example says that the input would be activated or focused, depending on platform convention.  <input> is an interactive element, so this contradicts the sentence in the paragraph above.

Suggest re-wording to:
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. The activation behavior of a label element for events targeted at <del>interactive content</del><ins>hyperlink</ins> descendants of a label element, and any descendants of those <del>interactive content</del><ins>hyperlink</ins> descendants, must be to do nothing.

(In reply to Cynthia Shelly from comment #4)
> The text is still there, and is still confusing.  In the example, the
> following markup is used
> <label><input type=checkbox name=lost> Lost</label>
> 
> The <input> is a child of the <label>.  The text in the example says that
> the input would be activated or focused, depending on platform convention. 
> <input> is an interactive element, so this contradicts the sentence in the
> paragraph above.
> 
> Suggest re-wording to:
> 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. The activation behavior of a label element for
> events targeted at <del>interactive content</del><ins>hyperlink</ins>
> descendants of a label element, and any descendants of those
> <del>interactive content</del><ins>hyperlink</ins> descendants, must be to
> do nothing.

Upon re-reading it does appear confusing, as you point out. 
How does replacing "interactive content" with "hyperlink" make it any clearer? 

I am inclined to agree that the meaning is clearer without the second sentence and either remove the second sentence or be more prescriptive about expected behaviour when a label contains mulitiple controls.

<label><input type="text"> <input type="text"> test</label>

note in the example above clicking on the label causes focus to be placed on the first input in browser i tested (in firefox/IE/chrome on windows)

So re-reading again - the preceding sentence to the one quoted states:
"If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element's labeled control."
http://www.w3.org/html/wg/drafts/html/master/forms.html#the-label-element

which covers the test case I put in the previous comment.

the intent of the second sentence  is to cover this case (i believe)


<label>Lost <input type=text name=lost id="lost"> </label>

<label for="lost">found <input type=text name=found id="found"> </label>

See Ian's Comment 2 "The sentence is question is required to make sure that if you click on a text field inside a <label> whose labeled control is another text field, you don't end up focusing the other text field (which would be rather confusing to users)."

from testing FF/IE/Chrome on windows 8, the behaviour is consistent, clicking on the second label focuses the first control, which appears contrary to what the spec is trying to stop.

what appears to be the case for the browsers tested is that for/id labelling overrides nested control labeling.

Cynthia, 

I think this tweak makes the sentence actually mean what its is supposed to

"The activation behavior of a label element for events targeted at interactive content descendants of <del>a</del> <ins>another</ins> label element, and any descendants of those interactive content descendants, must be to do nothing."

what do you think?

(In reply to steve faulkner from comment #7)
> Cynthia, 
> 
> I think this tweak makes the sentence actually mean what its is supposed to
> 
> "The activation behavior of a label element for events targeted at
> interactive content descendants of <del>a</del> <ins>another</ins> label
> element, and any descendants of those interactive content descendants, must
> be to do nothing."
> 
> what do you think?

I'm sorry but I don't see what is unclear with the initial wording. Also, the change you make seems to me problematic. You can't say "another" because it may be the same label. Consider:

<label>
  <input>
  <input>
</label>

The label's control is the first input. But if you click inside the second one you really don't want your focus to move to the first one.

Note also that this constraint isn't contradictory with the should match platform behaviour. If there is a platform that has this sort of crazy focus jumping behaviour, there's plenty of good reason to override it there.

I would suggest this be closed.

(In reply to Robin Berjon from comment #8)

> I'm sorry but I don't see what is unclear with the initial wording. 

OK so just to make sure common people like me can understand the scratchings:
what I think it is saying after re re re reading is

If a user clicks on a control that is inside a label do not trigger the labels activation behaviour. Only trigger the label activation behaviour for that part of the labels area that does not contain a control.

??

if this is not correct can you provide an explanation?

I like Steve's plain language description.  Can we use that?

Assigned to Steve Faulkner, on behalf of the HTML A11y TF.

Waiting for the HTML spec to be editable again...

This was dealt with in https://github.com/w3c/html/pull/113

fixed https://github.com/w3c/html/pull/113