Re: [csswg-drafts] [css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes? (#10795)

The CSS Working Group just discussed `[css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes?`, and agreed to the following:

* `RESOLVED: Close no change for now, unless someone comes back with clear use cases + proposal`
* `RESOLVED: Republished a new WD of css-cascade-6`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> miriam: we've discussed a few times, and there's a request for more research but unsure what the research should be<br>
&lt;emilio> ... right now we flatten scope proximity to a single value based on nearest scope<br>
&lt;emilio> ... it's probably a decent proxy for that<br>
&lt;emilio> ... nobody knows what the use case for nested scopes is, but you can do it<br>
&lt;emilio> ... not clear that is different from narrowing the scope<br>
&lt;emilio> ... I think the flat version works ok<br>
&lt;emilio> ... it'd be reasonable to lookup nested scope, but would be difficult to implement, and probably not necessary for authors<br>
&lt;emilio> ... other proposals in the thread I didn't quite like<br>
&lt;matthieud> q+<br>
&lt;emilio> emilio: so proposal is no change?<br>
&lt;emilio> miriam: I'd go for that but open to other options<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> +1 to no change<br>
&lt;emilio> +1<br>
&lt;TabAtkins> q+<br>
&lt;emilio> fantasai: I think what would happen most likely is for nesting scopes like different color schemes<br>
&lt;emilio> ... and I have wide / narrow layout, in a way they nest<br>
&lt;emilio> ... what's likely to happen is that the author was thinking about narrowing<br>
&lt;matthieud> @scope my-color-theme-purple { @ scope dark { ... color: something-dark-and-purple }}<br>
&lt;emilio> ... and so for some rules you care about the outer scope and for others the inner<br>
&lt;emilio> ... and we don't know which one is important<br>
&lt;emilio> ... I think we don't know the answer about which one is important<br>
&lt;emilio> ... in that thing they're likely to be different thing<br>
&lt;emilio> ... that's why we have both specificity and layering as escape hatches<br>
&lt;emilio> fantasai: neither layering or specificity control it because the question is which type of container I'm closest to (dark or light for example)<br>
&lt;emilio> ... if you have nested scopes you might have dark -> disabled or whatever<br>
&lt;emilio> ... but you might not know which proximity is more important<br>
&lt;emilio> ... I remember looking at it and thinking it can't be obvious which one to pick<br>
&lt;emilio> ... it's clear that if you're scoped double into something you want it more heavily weighted that only one level<br>
&lt;emilio> ... but in which way it's not clear<br>
&lt;emilio> miriam: hard to respond without an example but remember that scope is per-selector<br>
&lt;emilio> ... so I can ?? and then they'd look at the right scope<br>
&lt;emilio> ... and I can define a scope for my color and for my components and so on<br>
&lt;emilio> ... and they'd respond to the proximity of their scope independently<br>
&lt;astearns> ack matthieud<br>
&lt;emilio> matthieud: if you have a scope for a purple theme and then one for the dark, you are interested in both<br>
&lt;emilio> ... and at the beginning the proximity was ignored for the second one<br>
&lt;emilio> ... [example similar to fantasai]<br>
&lt;emilio> miriam: you need to care about both for it to become an issue<br>
&lt;emilio> ... for that example to become an issue you'd need dark -> light and purple -> green<br>
&lt;emilio> matthieud: which I guess can happen?<br>
&lt;emilio> ... but again these are only test-cases I write<br>
&lt;emilio> miriam: I think it's a bit of a theoretical example<br>
&lt;emilio> ... question would be would any of the other proposals solve it?<br>
&lt;emilio> ack TabAtkins<br>
&lt;astearns> ack TabAtkins<br>
&lt;emilio> TabAtkins: from what I can tell, that afaict is solved equally well by just not nesting scopes<br>
&lt;emilio> ... just single scopes with .purple.dark, .green.light, .green.dark, .green.dark<br>
&lt;emilio> matthieud: they might not be in the same element<br>
&lt;emilio> TabAtkins: ah, was wrong<br>
&lt;emilio> ... but larger concern is that people find specificity complicated<br>
&lt;emilio> ... but the more we try to add specificity-ish things...<br>
&lt;emilio> ... adding complexity here is going to give unexpected answers<br>
&lt;andruud> +1<br>
&lt;emilio> ... eg when they're interleaved<br>
&lt;emilio> ... so I'm concerned with adding more complexity<br>
&lt;emilio> ... given not every relationship can be represented here<br>
&lt;emilio> ... my opinion is that it's not worth the complexity + performance cost<br>
&lt;emilio> ... suggested middle-of-the-road compromise where number-of-scopes was also part of the calculation<br>
&lt;kizu> https://codepen.io/kizu/pen/gbaeprG — example<br>
&lt;emilio> ... but that also doesn't fix any of the issues<br>
&lt;emilio> lea: so what are you proposing<br>
&lt;emilio> TabAtkins: no change to the spec<br>
&lt;emilio> matthieud: we filter by both but proximity of the inner only<br>
&lt;emilio> fantasai: I think something's off but don't know how to fix it<br>
&lt;emilio> astearns: never has been clear who's going to do the research and dig into other solutions<br>
&lt;emilio> ... so I think we should close no change for now<br>
&lt;emilio> PROPOSED: Close no change for now<br>
&lt;emilio> fantasai: as long as it's clear that can be reopened if a new proposal comes up<br>
&lt;fantasai> PROPOSED: Close no change for now, unless someone comes back with clear use cases + proposal<br>
&lt;emilio> RESOLVED: Close no change for now, unless someone comes back with clear use cases + proposal<br>
&lt;emilio> miriam: this was the last issue of scope<br>
&lt;emilio> astearns: should we republish?<br>
&lt;emilio> miriam: it's already a WD<br>
&lt;emilio> astearns: should we resolve publishing a new WD with the intent that it becomes CR soonish?<br>
&lt;miriam> (last issue besides proposals for level 2 features)<br>
&lt;emilio> matthieud: yeah if we change proximity it's going to be a webcompat issue<br>
&lt;fantasai> level 7? :)<br>
&lt;emilio> RESOLVED: Republished a new WD of css-cascade-6<br>
&lt;emilio> s/Republished/Republish<br>
&lt;miriam> yes, level 7<br>
</details>


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


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

Received on Tuesday, 19 August 2025 13:45:48 UTC