- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Oct 2024 16:44:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes?`.
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> miriam: scopes add "proximity" to the cascade, which is the number of elements between the element and the scope root. closer proximity wins when there's a specificity tie<br>
<TabAtkins> miriam: the only use-cases we've seen rely on just that final step<br>
<andruud> q+<br>
<TabAtkins> miriam: rather, author's interest seems to be mostly in just that final step, nested scopes seem difficult to track impl wise and Anders suggests it's a perf issue too<br>
<TabAtkins> miriam: ??? was suggesting we could maybe have *some* way to tracking nested scopes<br>
<astearns> s/???/matthieud<br>
<TabAtkins> miriam: a proposal is a number that is the proximity distance, and number of scopes as a tiebreaker<br>
<emilio> q+<br>
<TabAtkins> miriam: I'd be happy with either leaving as is, or just going with scope count<br>
<astearns> ack andruud<br>
<emilio> q+ later<br>
<emilio> ack emilio<br>
<TabAtkins> andruud: the original proposal in the issue was a dynamic cascade criteria for proximity; i was really worried about the perf<br>
<TabAtkins> andruud: it wasn't as bad as I thought. was still some perf regression tho.<br>
<TabAtkins> andruud: so I still think that *if* we make a change, we shoudl go with the alternate proposal (just the count of scopes)<br>
<TabAtkins> andruud: simpler for impl, and I think simpler for authors to understand<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: i looked at the proposal; i had a question.<br>
<TabAtkins> fantasai: how sure are we that want to index only on the last scope proximity<br>
<TabAtkins> fantasai: would it make sense to consider which of the scopes is the "highest ranking"?<br>
<TabAtkins> fantasai: i could imagine, depending on your stylesheet structure, one or the toher would be more important<br>
<TabAtkins> miriam: would the importance be marked in some way?<br>
<romain> having a scope-end makes it more important, in a way<br>
<TabAtkins> fantasai: i dunno, could be an interesting qeustion<br>
<romain> having both a scope-start and scope-end vs. only having a scope-start<br>
<TabAtkins> fantasai: for the proximity distance, considering the highest rather than last could make sense ehre<br>
<fantasai> s/highest/strongest/<br>
<TabAtkins> andruud: we're talkinga bout nested scopes here. so isn't the innermost scope always closer to the subject than the outer scopes?<br>
<TabAtkins> miriam: yes<br>
<TabAtkins> miriam: the only way you'd change that is if you were measuring the distance between the scopes, but i don't know that that's useful<br>
<TabAtkins> matthieud: that's the same as counting the subjects, yeah<br>
<TabAtkins> andruud: the cascade is already really complex altogether, so I'd like to keep it as simple as possible<br>
<matthieud> s/counting the/counting from the/<br>
<bramus> +1<br>
<TabAtkins> miriam: i tend to agree<br>
<TabAtkins> +1, as simple as possible (but no simpler)<br>
<TabAtkins> miriam: definitely use-cases for measuring to nearest scope. maybe some cases for measuring to nested scopes, but not really common, and not sure where it's where proximity is most useful<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: was gonna bring same point as fantasai<br>
<TabAtkins> emilio: accounting only for proximity fo the closest feels a little weird<br>
<TabAtkins> emilio: leans me towards preferring no change if this isn't super useful<br>
<TabAtkins> emilio: you can get this sort of tied behavior by using nested selector<br>
<TabAtkins> emilio: using the & can pull in the specificity of the scope root<br>
<matthieud> q+<br>
<noamr> +1 to not adding implicit cascade rules on top of the existing ones<br>
<TabAtkins> fantasai: the trick woudl be to come up with realistic examples where you're nesting scopes and caring about the proximity of each<br>
<TabAtkins> fantasai: the canonical example of proximity is the light/dark switch, where you want to style based on which is the closest ancestor rather than stylesheet ordering<br>
<TabAtkins> fantasai: and if you combine that with other aspects that you might want -- let's say you had a "zoom" switch as well<br>
<TabAtkins> miriam: generally in that case they'll be written as separate scopes, not nested scopes<br>
<TabAtkins> emilio: if you were to nest them, the behavior would be extremely confusing<br>
<TabAtkins> I'm pretty strong on the side of "it woudl be extremely confusing" even if there is a use-case<br>
<astearns> ack matthieud<br>
<TabAtkins> matthieud: first question is about usage<br>
<TabAtkins> matthieud: seems we don't have an idea even about the usage of nested scope itself<br>
<TabAtkins> matthieud: shoudl we forbid nested scope altogether?<br>
<TabAtkins> matthieud: second, about impl. Anders, not sure if it's very different from current impl.<br>
<emilio> q+<br>
<TabAtkins> matthieud: Seems linear to the number of scopes<br>
<andruud> No<br>
<TabAtkins> matthieud: Haven't done the impl but doesn't seem particularly complex. And perf concern seems only to be about nested scopes, falt scopes seems fine<br>
<TabAtkins> emilio: The main problem is that this makes things that the cascade depends on dynamically sized, which means you need at least an extra pointer somewhere<br>
<TabAtkins> emilio: And that's extremely hot code<br>
<TabAtkins> emilio: so it's not the perf of looking for the scopes (agreed you already need to look thru them), it's about storing the list of appliable decl blocks<br>
<TabAtkins> emilio: if you have those along with cascade order, you have to grow them, and it grows unconditionally regardless of whether you use it, it causes cache misses, etc<br>
<TabAtkins> matthieud: okay if you alway shave an integer for scope is ee it. our impl always has a pointer<br>
<miriam> q?<br>
<TabAtkins> emilio: right, for us making ti a pointer would be a perf regression just going in<br>
<miriam> q+<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: so if it's mostly a theoretical purity thing we could avoid the perf hacks<br>
<TabAtkins> andruud: I'll say again that perf *would* be acceptable if you *did* want to do it that way. I thought it would be terrible, but it's merely uncofmortable. Doable if *needed*, I just don't want to.<br>
<astearns> ack miriam<br>
<TabAtkins> miriam: responding to first part about disallowing nested<br>
<TabAtkins> miriam: I don't think so<br>
<TabAtkins> miriam: i know the reasons for nesting scopes - to narrow in on a selector<br>
<TabAtkins> miriam: I haven't seen a use-case where that changes what proximity is doing<br>
<TabAtkins> miriam: so to me i don't see it as necessary that that effects in some strong way<br>
<TabAtkins> miriam: And the risk to disallowing entirely is, we'd have to remove scoping stylesheets, which we currently have on @import<br>
<TabAtkins> I think the use-case for nested scopes is clear.<br>
<TabAtkins> @scope my-component { @scope light {...}}<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: so the question is what use-cases are there for nesting scopes<br>
<TabAtkins> fantasai: would it make sense to have a blog post to collect feedback on this to get examples?<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/8380#issuecomment-1450475188<br>
<fantasai> @scope (A) {<br>
<fantasai> @scope (B) {<br>
<fantasai> X { color: blue }<br>
<fantasai> }<br>
<TabAtkins> fantasai: this is the preivous issue we had on the topic<br>
<fantasai> X { color: yellow }<br>
<TabAtkins> fantasai: I'd expect blue to always win inside the B scope<br>
<fantasai> TabAtkins: yellow would win if you have A inside B inside A<br>
<emilio> <A><B><A><X><br>
<TabAtkins> fantasai: so there's definitely some confusing stuff that happens when taking the outermost<br>
<TabAtkins> fantasai: dunno if we can resolve the confusion<br>
<TabAtkins> (I think it getting yellow in this case is probably the intended behavior, fwiw.)<br>
<emilio> q+<br>
<TabAtkins> fantasai: what behavior they expect is an interesting thing. probably nest step is to have a blog post on the CSSWG blog<br>
<TabAtkins> astearns: miriam says we already know why people nest scopes tho<br>
<TabAtkins> miriam: it would be the similar reason for nesting in general - "i want to drill down"<br>
<TabAtkins> miriam: Often, i've written a scope, but I only want to apply it in a certain place.<br>
<keithamus> q+<br>
<TabAtkins> fantasai: I think it's clear that we'll allow nested scopes. The proximity part is the - what would they use the proximity for rather than just the nested part of the scope<br>
<fantasai> s/we'll allow/people will use/<br>
<astearns> ack emilio<br>
<fantasai> s/nested part/limiting part/<br>
<TabAtkins> emilio: I can't think of any case where you'd nest a scope, but then - that weird situation where you have a lone thing you expect to be inside is outside [ed: i dunno what is being referred to here]<br>
<TabAtkins> emilio: i agree with fantasai that we should reach out about this<br>
<TabAtkins> emilio: I dont' think there's much @scope in the wild, but we could check httparchive<br>
<TabAtkins> emilio: so i don't think i could come up with a use-case that would intentionally break, feels weird to do<br>
<TabAtkins> keithamus: a commont hing i see in preprocessors is to drop in an @include, which might be a whole block of CSS including scoped CSS<br>
<keithamus> ack keithamus<br>
<astearns> ack keithamus<br>
<TabAtkins> keithamus: i have no concept about what that might change, jsut throwing out an example. possibly just accidental that it happens, but it could be a way for nested scopes to happen<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: yeah, that's an interesting question. if you have an outer @scope, and you drop rules in, and you expect rules in the scope to defeat things with a weaker proximity<br>
<TabAtkins> fantasai: First block of @scope is 10 proximity, next is 6. Then inside it, we have another rule with an @scope...<br>
<TabAtkins> [i have no idea what this example is]<br>
<TabAtkins> miriam: remember that no block has a score ,it comes from the dom<br>
<noamr> IMO we should leave score around imports to layers rather than add all kinds of default behavior around this<br>
<TabAtkins> fantasai: i dunno i'm confused<br>
<TabAtkins> Agreed, noamr<br>
<stepheckles> q+<br>
<TabAtkins> emilio: so it's not true that the inner scope is always the most relevant for the comparison<br>
<TabAtkins> stepheckles: just thinking thru scenarios where someone would nest<br>
<astearns> ack stepheckles<br>
<TabAtkins> stepheckles: imagine they're nesting just becuase it's now available<br>
<TabAtkins> stepheckles: some authors might miss the part where @scope doesn't add specificity<br>
<TabAtkins> stepheckles: Adding that detail might be useful when asking for details<br>
<TabAtkins> astearns: So let's take this back to the issue and bring it back when we have more clarity/examples<br>
<TabAtkins> miriam: emilio, i didn't catch what you were referring to when you were saying inner scope wasn't alway smost relevant<br>
<TabAtkins> emilio: in the A-B-A-X case<br>
<TabAtkins> miriam: right, that's the point i was making, it's not the innermost *rule*, it's the nearest scope root<br>
<TabAtkins> (Yes, that's the proximity we use in the spec)<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-2432831651 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 October 2024 16:44:30 UTC