Csswg-drafts: [css-selectors] Make <label> elements reflect CSS pseudoclasses on associated form element

[gregwhitworth]

This discussion was taking place in the WHATWG, moving this over to the CSSWG repo so all CSS members see it and are able to engage. For reference, here is the issue for more context: https://github.com/whatwg/html/issues/1632#issuecomment-238429326

[gregwhitworth]

@frivoal To answer your question, it is still in Edge but off by default behind a flag as no other browser currently implements it this way.

[bkardell]

@gregwhitworth do all of them work in edge with the flag? :checked etc?

[gregwhitworth]

@bkardell No it doesn't propagate those, I've updated the testcase to include those http://jsbin.com/munatiyega/edit?html,css,output

[fantasai]

Related discussion on www-style. (This issue keeps coming up.)

[therealglazou]

This is a 18 years old discussion in the CSS WG (see _Reference Combinator_ in https://lists.w3.org/Archives/Member/w3c-css-wg/2000JulSep/0214.html and we already discussed it back in '97...) : I think we should not solve the individual <label> case directly but have a generic mechanism for ID/IDREF references. There are many other ID/IDREF cases in dozens of XML dialects that could benefit from such a generic mechanism, including in EPUB.

[tigt]

@therealglazou That would be nice, but <label>s can also be associated with descendant form elements without ID/IDREFs, so this seems to have a slightly larger scope.

As an author, this is a somewhat silly example of what I would love to use this functionality for:

<label>2 + 2 = ?
  <svg><use href="#correct" /><use href="#incorrect" /></svg>
  <input name="answer" pattern="4" required />
</label>

use {
  display: none;
}

label:valid > [href="#correct"],
label:invalid > [href="#incorrect"] {
  display: inline;
}

It’s sort of possible today to do this by placing the elements after the form element in question and using something like input:valid ~ foo, but that can be impossible with certain markup output — it’s common to wrap <select> inside a <span> for styling purposes, for example.

[TUSF]

As someone who's never worked on a layout engine, I have trouble understanding how this would add much more complexity. The argument against it I saw is that the engine would have to keep track of the element of the associated input. But UAs _already_ do this to some extent—a <label> is almost treated as an extension of its referenced input, allowing you to click a label to tick a checkbox or radio button.

To me, this feature just seems implied from the already present behavior, but perhaps I'm misunderstanding something.

[css-meeting-bot]

The CSS Working Group just discussed <label> elements, and agreed to the following:

• RESOLVED: Push this out to Level 5

The full IRC log of that discussion

<presenter> Topic: <label> elements

<astearns> github: https://github.com/w3c/csswg-drafts/issues/397

<presenter> AmeliaBR: I brought this up on WHATWG because the relevant text is in HTML, but they threw it back to CSS.

<presenter> AmeliaBR: Often you want to do some styling on the label or on gencon that depends on :required or :invalid or :focus on the label's associated inputl

<presenter> AmeliaBR: Right now the only way to do that is by modifying your DOM structure so the label is a following sibling of the input.

<presenter> AmeliaBR: Having to modify your DOM to do styling is iffy, there are some cases where this can't work.

<presenter> AmeliaBR: And it also means you can't use the implicit association of label with child inputs; you have to use IDs, which can cause problems in dynamic content.

<presenter> AmeliaBR: So the suggestion was that the <label> should reflect the form-related pseudos, and :focus/:hover, of the associated form element.

<presenter> AmeliaBR: Last time this was discussed there were some perf concerns, but labels already have a DOM association (you can chase a DOM property to see the associated input)

<xfq> WHATWG issue: https://github.com/whatwg/html/issues/1632

<astearns> some concerns from bz: https://github.com/whatwg/html/issues/1632#issuecomment-238301486

<presenter> AmeliaBR: As I recall there is something in the HTML spec about how focus or hover already propagates in a certain way...

<presenter> myles: People use labels and form controls everywhere already, is this gonna break anything?

<presenter> AmeliaBR: If you've got label:invalid that currently does nothing, then it could be an issue.

<presenter> AmeliaBR: Or perhaps some of the more common pseudos

<presenter> TabAtkins: I think :hover is the most likely to see some new stuff

<presenter> emilio: Eh, reasonable to see form :invalid, would trigger more.

<presenter> emilio: And the fact that labels can be anywhere in the DOM (current state propagation, like to fieldset, is just parent/ancestor-based), talks to BZ's concern about this being one more thing to slow things down.

<bkardell_> I see

<AmeliaBR> label:for(:required)

<presenter> AmeliaBR: On the perf issue, it's worth remembering that labels and inputs already have DOM properties that link to each other. But they probably aren't used much, so they might be slow getters, I dunno.

<presenter> emilio: Also worth noting that CSS needs a 2-way link; label->input for the selector, but input->label for invalidation

<astearns> tab: suggests houdini

<bkardell_> will note that I just yay'ed to a thing that wasn't in the minutes :)

<AmeliaBR> Re DOM APIs, labels have a control property, while labelable elements have labels (node list) https://html.spec.whatwg.org/multipage/forms.html#dom-lfe-labels

<fantasai> TabAtkins: In general I'd say resolve to reject at this point, since still implementer resistence on perf grounds. Which makes me sad because I've run into these exact problems.

<bkardell_> can we note the "waves hands and invokes potential houdini solution" int he rejects notes

<fantasai> astearns: Not really a rejection, just no implementer interest yet

<fantasai> TabAtkins: Yeah, not going in as expected feature of the spec atm

<fantasai> AmeliaBR: If we do it in the way Tab proposes, to avoid any back-compat issues with :for() pseudo

<fantasai> AmeliaBR: So there's a CSS issue and a WHATWG issue

<fantasai> AmeliaBR: CSSWG says if we do this, this is how we do

<fantasai> astearns: And try it out iwht Houdini

<fantasai> TabAtkins: I still have to finish TypedOM, but custom selectors will rpobably be next

<fantasai> hober: There's the ? work to do association without IDREFs, using direct assignment. Should probably tie in with that

<hober> s/?/AOM/

<fantasai> TabAtkins: I recently had discussions with ppl about solving problems, can we have a selector associated with a map that I have created

<fantasai> TabAtkins: seems like would solve a lot of problems

<hober> https://github.com/WICG/aom/issues/2

<fantasai> TabAtkins: should be part of houdini work

<fantasai> RESOLVED: Push this out to Level 5

[SebastianZ]

I am strongly opposed to let labels directly reflect the pseudo-classes of the associated form control.

1. The state of the form control doesn't apply to the label. E.g. it's the form control that is focused, not the label.
2. Letting pseudo-classes behave differently depending on whether they are prepended by label or not is confusing.
3. Letting the pseudo-classes apply to labels now may break existing websites.

Therefore, solving this use case via a pseudo-class function like :for() as discussed in #1067 is much more logical, in my eyes. Furthermore a function like that has the advantage of being extensible and covering more than just form control states.

Sebastian