This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #27292 +++ The label element has some restrictions in the fact that it can contain no form controls but its labeled control, and it can't contain other label elements. However, one more restriction should apply: it shouldn't be allowed to contain any <a> element with a @href attribute, because on some user agents (I tested it on Chrome, latest version as of now) clicking on link prevents the control state change behavior, even if the link points to a different browsing context (e.g. iframe, popup, new tab). Or probably it shouldn't contain any interactive element, for the same reason: conflict arises between events. http://www.w3.org/TR/html5/forms.html#the-label-element
See bug 27292 comment 1.
This is definitely intentional as written. I believe Chrome is buggy here — the way label is specced is supposed to make this work out ok.
How so? Does this mean that a link (<a> element) inside a <label> should both navigate the link and change the control state? Then I'm afraid that Chrome, IE, Firefox, Opera and Android are all buggy. A link inside a label always brings to navigating the link itself, while the control state doesn't change. Which doesn't mean that the control itself is ignored. Where the control has an active state which is visually evident, it changes color as far as the <label> is active (i.e. the mouse button is pressed). But the final state is not changed. This applies to internal anchor links and link to different browsing contexts as well, both in nested controls and in those referred to via @for.
Clicking a link in a label is supposed to just follow the link and not touch the label's control. I understood comment 0 as saying that Chrome didn't do this, but it looks like I misread it. If we're all agreed that the spec and all the implementations match, then I'm confused as to what the bug is.
The style changing is a result of the weird legacy :active behaviour. I tried not having that but had to change the spec to match implementations because apparently sites depend on it. I think this is WORKSFORME.
Simon, this seems to be waiting on you to say resolve or not, based on your response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=27293#c5
The clonee bug has some examples that might not work so well, but it's pretty common to have something like <label><input type=checkbox ...> I have read and agree to <a href>terms of service</a></label> which, apart from confusing :active style applying on the checkbox when clicking the link, works as intended AFAICT. If you want :active changed, please file a new issue at https://github.com/whatwg/html/issues