[css-cascade-6] Do we want to defer some or all of these scope extensions to level 7?

[mirisuzanne]

Two of the open issues related to @scope are related to defining extensions to the syntax:

• [cascade-6] Unclear proximity for scoped descendant combinator #8380 attempts to resolve complexity in 'scope proximity combinators' (>>/~~)
• [css-cascade-6] Handle sibling-proximity in @scope #7751 proposes an alternative 'sibling-scope' rule for generating DOM-horizontal scopes

Before we get into discussing and resolving on the details, I just want to note that neither is a core requirement for shipping the existing scope syntax. If we want to defer them to a future spec, the current scope rule can ship uninhibited. To consider each one at a time:

• The scope combinators are a syntax sugar over behavior that can already be achieved using @scope - but with the added complexity of resolving multiple subjects from a single selector. These may be worth pursuing, but it's not clear that there is a strong need for them - or that the 'semi-de-sugaring' solution proposed will make sense in practice. To me, these feel non-essential.
• The sibling-scope proposal has a stronger and more distinct use-case, but not an extremely common one. Since it would reflect the @scope rule more precisely, it may also be simpler to spec -- but not trivial.

I think both discussions are worth pursuing. I also think both could be deferred in order to ship the central functionality here.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-6] Do we want to defer some or all of these scope extensions to level 7?, and agreed to the following:

• RESOLVED: The combinator is deferred

The full IRC log of that discussion

miriam: Some tagalong features we can consider; all are useful, question is whther we shoudl be trying to cover them now or defer to next spec level
…If we don’t defer them, next on the agenda is a scope sibling feature
…This would be horizontal in the DOM
…A pretty straightforward thing to spec, we think, but it hasn’t been specced
…The other is the scoped proximity combinators
…We have a little less sense when people would use this rather than @scope
…For @scope you’re trying to target several elements in the DOM, and the at-rule does that neatly
…In a single selector, it gets more complex
+1 to deferring, they're all nice but none are necessary
…The real question is: defer, or no?
astearns: One concern with deferring is there may be feedback with current-level features that could modify
…If we’re not considering these now, we may miss something
miriam: It’s hard to know if that’s too cautious
…So far neither has caused major changes and will continue to be in our heads, but I dunno
TabAtkins: My estimate is they shouldn’t cause any problems, and should be forward-compatible
astearns: Would it make sense to have a note about things we’ve explicitly deferred?
q+
miriam: Since one is partically-specced, it could be opening another spec
ack bramus
s/partically/partially/
bramus: I’m okay with deferring combinators due to complexity, but was wondering if we can have sinling scope in level 6
s/sinling/sibling/
Implementation-wise they seem a bit trickier than descendant scopes fwiw
astearns: What use case are you concerned about with sibling proximity?
Because to change the descendant relationship you need to remove from the DOM but that's not true for siblings
bramus: So authors can style things like start and end dates on a calendar and also styles things between them
miriam: Another example is to style everything between one header and the next header
ack fantasai
fantasai: Seems like those are use cases where you don’t need scope proximity effect, you just want the flooring effect, yes?
miriam: I think I’ve seen examples using both
…They achieve the same goal, but at different levels of explicitness and power
I have made the request to generate https://www.w3.org/2023/03/22-css-minutes.html fantasai
astearns: Can we resolve on deferring the combinator?
…Proposing deferring 8380 with a note that it was deffered to next level
RESOLVED: The combinator is deferred