Re: [csswg-drafts] [css-nesting-1][css-cascade-6] Should/can relative selectors be allowed un-nested (#12418)

The CSS Working Group just discussed `[css-nesting-1][css-cascade-6] Should/can relative selectors be allowed un-nested`, and agreed to the following:

* `RESOLVED: Close no change.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> fantasai: Might've been useful to have Tab at this breakout<br>
&lt;fantasai> miriam: This was raised by Lea wrt if a whole file is scoped on import<br>
&lt;fantasai> miriam: If those items are relative selectors ...<br>
&lt;fantasai> miriam: Should we allow relative selectors at every level of CSS including the root?<br>
&lt;fantasai> miriam: If so, what would it mean?<br>
&lt;fantasai> miriam: My leaning is that we don't need to do this<br>
&lt;fantasai> miriam: Tab had some concerns with it<br>
&lt;fantasai> miriam: For example, a relative selector with a child combinator is meaningless in relation to the root<br>
&lt;fantasai> miriam: similarly ??<br>
&lt;fantasai> miriam: And normal descendant selector doesn't need to be relative until imported into a scope<br>
&lt;fantasai> miriam: So not really combinators that are meaningful to do at the root level<br>
&lt;andruud> q+<br>
&lt;astearns> ack andruud<br>
&lt;andruud> Just move on for a bit then<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> scribe+<br>
&lt;emilio> fantasai: the child combinator [drop]<br>
&lt;matthieud> q+<br>
&lt;emilio> matthieud: what's the point of having relative top level selectors?<br>
&lt;emilio> ... if we allow these is it only working when we `@import` scope() something?<br>
&lt;emilio> miriam: leaverou was expecting it to be relative to `:root` by default, but as tab pointed out that's not particularly useful<br>
&lt;emilio> ... so that's why I suggest no-change<br>
&lt;emilio> ... once we import in scopes I think people may want to do it but I don't think it makes sense to make it valid or not depending on the way it's important<br>
&lt;kizu> +1 to no change<br>
&lt;emilio> matthieud: agree that they can just wrap in `:scope`<br>
&lt;emilio> miriam: or prefix each selector yeah<br>
&lt;emilio> fantasai: I think it's fine<br>
&lt;emilio> emilio: +1 fwiw<br>
&lt;emilio> astearns: if we're wrong and this is something people are going to use often<br>
&lt;emilio> ... and litter their sheets with `:scope`, how frustrating is that going to be?<br>
&lt;emilio> q+<br>
&lt;emilio> ack matthieud<br>
&lt;astearns> ack matthieud<br>
&lt;emilio> miriam: not sure who's going to complain about it<br>
&lt;emilio> ... but I think it's more explicit when you litter it with `:scope`<br>
&lt;emilio> ... so I think it's still the right choice<br>
&lt;emilio> ... it also raises the question of also allowing bare declarations in `@scope`, do we want to allow bare declarations in a css file?<br>
&lt;kizu> +1, explicit > implicit<br>
&lt;fantasai> emilio: You don't have to use :scope everywhere, right, can just wrap whole style sheet in @scope<br>
&lt;fantasai> emilio: so even if you wanted to do this, only need to add 2 lines of CSS ... and technically don't even need the closing bracket<br>
&lt;astearns> ack emilio<br>
&lt;emilio> s/@scope/:scope {`<br>
&lt;emilio> s/@scope/:scope {/<br>
&lt;fantasai> miriam: only needed for sibling or child combinator. Most styles are descedant combinators anyway<br>
&lt;fantasai> miriam: and sibling is out of scope<br>
&lt;fantasai> andruud: I'm happy with the discussion so far<br>
&lt;romain> +1 to no change<br>
&lt;emilio> +1<br>
&lt;fantasai> astearns: Proposed resolution, closed no change. Objections?<br>
&lt;fantasai> RESOLVED: Close no change.<br>
</details>


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


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

Received on Wednesday, 2 July 2025 15:14:44 UTC