Re: [csswg-drafts] [selectors][css-nesting] Move nest-containing and nest-prefixed selector definitions to Selectors (#5745)

The CSS Working Group just discussed this issue, and agreed to the following:

* `RESOLVED: Accept to make & valid everywhere, maps to :scope where not otherwise defined`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic:<br>
&lt;fantasai> 5. [selectors][css-nesting] Move nest-containing and nest-prefixed selector definitions to Selectors<br>
&lt;fantasai> github:<br>
&lt;fantasai> 5. [selectors][css-nesting] Move nest-containing and nest-prefixed selector definitions to Selectors<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5745#issuecomment-1271874448<br>
&lt;fantasai> TabAtkins: separate from discussion of which exactly nesting syntax<br>
&lt;fantasai> TabAtkins: all of our proposals use the &amp;<br>
&lt;fantasai> TabAtkins: we have a few different contexts where we do nesting<br>
&lt;fantasai> TabAtkins: and they don't currently allow &amp;<br>
&lt;fantasai> TabAtkins: right now assumption is that &amp; only has meaning and possibly only valid in direct nesting<br>
&lt;fantasai> TabAtkins: this is not great, particularly if use &amp; > .foo<br>
&lt;fantasai> TabAtkins: meaning of this is clear in any nestable context<br>
&lt;fantasai> TabAtkins: so being able to copy-paste rule between different things, from nesting to @scope or querySelector<br>
&lt;fantasai> TabAtkins: even globally, makes sense, just say parent context is :root<br>
&lt;fantasai> TabAtkins: similarly in shadow DOM<br>
&lt;fantasai> TabAtkins: so proposal is, to avoid authors being forced to edit selectors as they move nesting context<br>
&lt;fantasai> TabAtkins: defined &amp; to be valid and to have meaning in other context<br>
&lt;fantasai> TabAtkins: if not defined specially, is equivalent to :scope<br>
&lt;fantasai> TabAtkins: and this is already defined globally, top level it is host element of shadow stylesheet or :root otherwise<br>
&lt;fantasai> TabAtkins: so make this analogous unless context explicitly defines it analogously<br>
&lt;fantasai> florian: Seems reasonable, but haven't thought about it much<br>
&lt;fantasai> Rossen_: I'm convinced, too<br>
&lt;fantasai> Rossen_: Objections?<br>
&lt;fantasai> ??: Gotten to comments about how used inside scope would be referencing, if possible to get up to another nested context<br>
&lt;fantasai> ??: Getting confused to understand, anyone can describe clearly?<br>
&lt;fantasai> ??: "What would the below example be? Would be unable to reference :scope in a nested context"<br>
&lt;TabAtkins> (comment is https://github.com/w3c/csswg-drafts/issues/5745#issuecomment-1271646202)<br>
&lt;dbaron> s/??/PaulG/<br>
&lt;florian> s/??/PaulG/<br>
&lt;fantasai> The answer is later in the thread, where the call was to not to change meaning of :scope<br>
&lt;fantasai> s/??/PaulG/<br>
&lt;fantasai> TabAtkins: Doesn't change the meaning, &amp; is always using the local definition of it<br>
&lt;fantasai> TabAtkins: Question was if you put nested style rule under the img style rule, what would &amp; refer to, it would refer to img<br>
&lt;fantasai> TabAtkins: Direct nesting doesn't change :scope<br>
&lt;fantasai> PaulG: Thanks<br>
&lt;fantasai> Rossen_: Back to objections?<br>
&lt;fantasai> RESOLVED: Accept to make &amp; valid everywhere, maps to :scope where not otherwise defined<br>
</details>


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


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

Received on Wednesday, 12 October 2022 16:49:30 UTC