- From: andruud via GitHub <noreply@w3.org>
- Date: Mon, 01 Sep 2025 13:24:55 +0000
- To: public-css-archive@w3.org
I am still trying to understand the ideas in this issue. I feel like this is more complicated than it needs to be, and/or that I'm missing something. Looking at this another way for a bit, imagine that we have two (not necessarily web-exposed) primitives: * The pseudo-child combinator (`:>`), as [seen elsewhere](https://github.com/w3c/csswg-drafts/issues/7346#issuecomment-1176857832). * A pseudo-_class_, `:pseudo()`, which checks if some element has a specific pseudo element type. Example: `:pseudo(before)`. * This exists to make it clear that we're querying a pseudo element type (and not a tag name) _without_ having to care about adjacent combinators. Looking at the original problem statement: ``` .foo { &, &::before, &::after { &:hover { color: blue; } } } ``` We can think of that as the following: ``` .foo { &, & :> :pseudo(before), & :> :pseudo(after) { &:hover { color: blue; } } } ``` Even if we use `:is()` directly, this should still match all of `.foo:hover, .foo::before:hover, .foo::after::hover` without violating the selectors data model: ``` :is(.foo, .foo :> :pseudo(before), .foo :> :pseudo(after)):hover {} ``` --- > I think it is somewhat unreasonable [that `::before { :hover& {} }` would desugar to `:hover::before { }`] Thinking about it more, yeah, agree. Should be `::before:hover {}`. -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9702#issuecomment-3242371729 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 September 2025 13:24:56 UTC