Re: [csswg-drafts] [css-selectors] Make <label> elements reflect CSS pseudoclasses on associated form element (#397)

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

* `RESOLVED: Push this out to Level 5`

<details><summary>The full IRC log of that discussion</summary>
&lt;presenter> Topic: &lt;label> elements<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/397<br>
&lt;presenter> AmeliaBR: I brought this up on WHATWG because the relevant text is in HTML, but they threw it back to CSS.<br>
&lt;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<br>
&lt;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.<br>
&lt;presenter> AmeliaBR: Having to modify your DOM to do styling is iffy, there are some cases where this can't work.<br>
&lt;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.<br>
&lt;presenter> AmeliaBR: So the suggestion was that the &lt;label> should reflect the form-related pseudos, and :focus/:hover, of the associated form element.<br>
&lt;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)<br>
&lt;xfq> WHATWG issue: https://github.com/whatwg/html/issues/1632<br>
&lt;astearns> some concerns from bz: https://github.com/whatwg/html/issues/1632#issuecomment-238301486<br>
&lt;presenter> AmeliaBR: As I recall there is something in the HTML spec about how focus or hover already propagates in a certain way...<br>
&lt;presenter> myles: People use labels and form controls everywhere already, is this gonna break anything?<br>
&lt;presenter> AmeliaBR: If you've got `label:invalid` that currently does nothing, then it could be an issue.<br>
&lt;presenter> AmeliaBR: Or perhaps some of the more common pseudos<br>
&lt;presenter> TabAtkins: I think :hover is the most likely to see some new stuff<br>
&lt;presenter> emilio: Eh, reasonable to see `form :invalid`, would trigger more.<br>
&lt;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.<br>
&lt;bkardell_> I see<br>
&lt;AmeliaBR> `label:for(:required)`<br>
&lt;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.<br>
&lt;presenter> emilio: Also worth noting that CSS needs a 2-way link; label->input for the selector, but input->label for invalidation<br>
&lt;astearns> tab: suggests houdini<br>
&lt;bkardell_> will note that I just yay'ed to a thing that wasn't in the minutes :)<br>
&lt;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<br>
&lt;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.<br>
&lt;bkardell_> can we note the "waves hands and invokes potential houdini solution" int he rejects notes<br>
&lt;fantasai> astearns: Not really a rejection, just no implementer interest yet<br>
&lt;fantasai> TabAtkins: Yeah, not going in as expected feature of the spec atm<br>
&lt;fantasai> AmeliaBR: If we do it in the way Tab proposes, to avoid any back-compat issues with :for() pseudo<br>
&lt;fantasai> AmeliaBR: So there's a CSS issue and a WHATWG issue<br>
&lt;fantasai> AmeliaBR: CSSWG says if we do this, this is how we do<br>
&lt;fantasai> astearns: And try it out iwht Houdini<br>
&lt;fantasai> TabAtkins: I still have to finish TypedOM, but custom selectors will rpobably be next<br>
&lt;fantasai> hober: There's the ? work to do association without IDREFs, using direct assignment. Should probably tie in with that<br>
&lt;hober> s/?/AOM/<br>
&lt;fantasai> TabAtkins: I recently had discussions with ppl about solving problems, can we have a selector associated with a map that I have created<br>
&lt;fantasai> TabAtkins: seems like would solve a lot of problems<br>
&lt;hober> https://github.com/WICG/aom/issues/2<br>
&lt;fantasai> TabAtkins: should be part of houdini work<br>
&lt;fantasai> RESOLVED: Push this out to Level 5<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/397#issuecomment-467205374 using your GitHub account

Received on Monday, 25 February 2019 22:13:40 UTC