- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Mar 2025 15:00:02 +0000
- To: public-css-archive@w3.org
> * Remember that `&` represents the elements (and now, pseudo-elements) matched by the parent selector; it's _not_ textual substitution. So `::before { :hover& {...}}` is equivalent to `::before:hover`, not `:hover::before` - the parent selector filters the match set to all the ::before pseudos, then `:hover&` represents elements that are (a) in the parent's match set, and (b) hovered. Then ideally we would disallow `&` except at the start of the compound? It's not unreasonable to expect `:hover::before` here. I get that it's consistent with the "filtering" model, but this will surely be seen as your selector being silently re-ordered. > you can't do the equivalent of `.foo { &, & > .bar {...}}` This would then desugar to: `.foo = (&) { ... }, .foo = (& > .bar) { ... }`? > `.foo = (*, ::before, ::after) = :hover {...}` Are there any restrictions on where lists with pseudos can appear - Can anything follow it (that is not allowed parse time today)? `.a = (.b, ::after) = .c {...}`. > Since it's part of a complex selector and guaranteed to be surrounded by combinators What does `&` refer to here? `.a = (.b, .c = (&)) = .d` > The pseudo-element "selector" is a legacy syntax mistake from the early days of CSS, and today would have been instead done as a type of combinator Is there anything that could be improved in this proposal if we _first_ fix that mistake (as an alternative way to access pseudo elements), and then make _that_ form work well with nesting? -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9702#issuecomment-2710892720 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 March 2025 15:00:03 UTC