Re: [csswg-drafts] [selectors-4] Allow more pseudo-classes following a pseudo-element (#7085)

The CSS Working Group just discussed `Allow more pseudo-classes after pseudo-elements`, and agreed to the following:

* `RESOLVED: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have`
* `RESOLVED: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.`
* `RESOLVED: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Allow more pseudo-classes after pseudo-elements<br>
&lt;fantasai> TabAtkins: Currently, pseudo-elements allow a few pseudos to be put after them, :hover etc.<br>
&lt;fantasai> TabAtkins: question is whether to allow combinatoric ones (:is()/:not()/:where()) to be applied as well<br>
&lt;JakeA> q+<br>
&lt;fantasai> TabAtkins: Further, some pseudo-elements represent specific elements elsewhere in the DOM<br>
&lt;fantasai> TabAtkins: wondering if specific pseudo-elements can opt into allowing additional pseudo-elements<br>
&lt;fantasai> TabAtkins: but that's a different issue<br>
&lt;fantasai> TabAtkins: but first issue, allowing combinatoric ones<br>
&lt;fantasai> TabAtkins: Contents are still restricted to the user-action pseudos<br>
&lt;fantasai> JakeA: we're interested in this for view-transitions<br>
&lt;Rossen_> ack JakeA<br>
&lt;fantasai> JakeA: want to know if old or new view is only-child<br>
&lt;fantasai> JakeA: so allowing that would be useful<br>
&lt;TabAtkins> fantasai: two issues, one is we have a set of pseudos that are already allowed, and do we allow them to be put in :is()/etc<br>
&lt;TabAtkins> fantasai: second is allowing other pseudos on case-by-case basis, we should talk about that separately<br>
&lt;TabAtkins> fantasai: for is/not/where, it's about whether we can express the combinations of the user action pseudos<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/pull/8041/files<br>
&lt;tantek> could see this being useful for webdevs<br>
&lt;fantasai> oriol: these use forgiving parsing, would invalid pseudos be valid within them?<br>
&lt;fantasai> TabAtkins: yes<br>
&lt;fantasai> TabAtkins: this would allow more safely adding more pseudo-classes to a selector in the future<br>
&lt;fantasai> Rossen_: any other opinions?<br>
&lt;fantasai> TabAtkins: proposed, allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have<br>
&lt;fantasai> RESOLVED: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have<br>
&lt;TabAtkins> fantasai: and more generically i want to resolve that the logical-combo pseudos can be used *anywhere* their contents are allowed<br>
&lt;TabAtkins> TabAtkins: I agree with being more generic if we can get away with it<br>
&lt;fantasai> fantasai: wanted to ask if anyone saw a problem with that<br>
&lt;tantek> no objection<br>
&lt;TabAtkins> (Don't think there's much issue beyond just implementing it.)<br>
&lt;TabAtkins> RESOLVED: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.<br>
&lt;fremy> q+<br>
&lt;fantasai> TabAtkins: Second part of issue, should we allow additional pseudo-classes other than user-action pseudo-classes to be put after speudo-elements?<br>
&lt;fantasai> s/speu/pseu/<br>
&lt;fantasai> fremy: On previous resolution, does that mean you can change styles on ::before:hover ?<br>
&lt;fantasai> TabAtkins: yes<br>
&lt;fantasai> fremy: what if you create a loop with ::first-line:hover?<br>
&lt;fantasai> TabAtkins: hover loop, we already have that problem<br>
&lt;fantasai> Consider p:hover ::first-line<br>
&lt;fantasai> fremy: ok<br>
&lt;JakeA> I'm still +1 this<br>
&lt;bradk> +1<br>
&lt;fantasai> TabAtkins: back to issue, should we allow lifting restrictions on pseudo-elements followed by pseudo-classes?<br>
&lt;argyle> +1<br>
&lt;miriam> +1<br>
&lt;JakeA> q+<br>
&lt;Rossen_> ack fremy<br>
&lt;TabAtkins> fantasai: Okay as long as we do it as an allowlist, rather than blanket allowing<br>
&lt;Rossen_> ack JakeA<br>
&lt;TabAtkins> JakeA: would folks be happy with us using :only-child for view transitions?<br>
&lt;fantasai> TabAtkins: As long as it matches intent<br>
&lt;fantasai> TabAtkins: defined as up to two children, and this one says if you have only one<br>
&lt;fantasai> JakeA: But usually it doesn't count pseudos...<br>
&lt;fantasai> JakeA: but I guess if we're appying it to a pseudo<br>
&lt;bradk> :only-pseudo-element?<br>
&lt;fantasai> TabAtkins: pseudo-elements live in the tree<br>
&lt;TabAtkins> RESOLVED: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 23 November 2022 17:56:55 UTC