[css-cascade-6] Handle sibling-proximity in @scope

[tabatkins]

Branching off of #7233...

Currently, >> is a shorthand for writing an @scope. That is, anytime you see .foo >> .bar {...}, it's equivalent to @scope .foo { .bar {...}}.

Now that we've agreed to add ++ (or ~~) to do sibling proximity, it would be nice to keep the consistency between the two syntaxes.

I suggest @scope siblings ... {}, where the ... is the current scope prelude stuff. If you specify siblings the lower bound, and all contained selectors, are auto-scoped to be siblings of the upper bound element, and we apply sibling-distance proximity as the tiebreaker rather than ancestor-distance proximity.

Need to be careful with the definitions to make sure descendant-scopes can still be nested; I guess descendant-scopes would scope the upper bound as a sibling but switch back to normal scoping for their lower bound. I believe this'll reproduce the behavior of .foo >> .bar ++ .baz >> .qux.

[ByteEater-pl]

Shouldn't that be @scope (.foo) { .bar {...}} per spec? (Otherwise elements with tag name siblings would collide with the proposed feature.)

[mirisuzanne]

yes, the root selector is in parenthesis. So this pattern would be something like @scope siblings (.foo) {} if we go with a keyword approach. (I don't have a better idea for it off-hand)

[bramus]

I had this idea of changing the to keyword itself to siblings and let that be the differentiating factor, e.g.

• @scope (.foo) siblings (.bar) { … }
• @scope (.foo) siblings { … }

Reasons not to like that:

• It’s not clear upfront that you’re going to scope between siblings. You first need to read the upper boundary selector (which might be long) and then come to know you’re doing a siblings-scope.
• Weird to see when no lower boundary is defined

I don’t think an extra at-rule (e.g. @sibling-scope) is feasible, to keep the number of at-rules in check?

[tabatkins]

I'm actually not sure if there are impl constraints that would encourage us to keep the number of at-rules in check or not. If not, @sibling-scope might very well be the most readable variant, clearly suggesting both that it's tied to @scope, and that it's different.

[bramus]

Agenda+ to decide between @scope siblings and @sibling-scope. Proposal to go for @sibling-scope.

[andruud]

I'm actually not sure if there are impl constraints that would encourage us to keep the number of at-rules in check or not.

I don't think there are such constraints.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-6] Handle sibling-proximity in @scope, and agreed to the following:

• RESOLVED: The name will be @scope-siblings

The full IRC log of that discussion

<emeyer> bramus: In regular scope, we can walk down the DOM tree
<emeyer> …Suggestion here is to introduce sibling proximity where the lower boundary is a sibling of the upper boundary element
<emeyer> …Syntax would be the same as @scope rule; different would be the at-rule would be @sibling-scope
<emeyer> s/different/difference/
<astearns> ack fantasai
<emeyer> fantasai: With normal scoping, relationships are obvious, but here we’re only doing following siblings, so should make that a little more obvious
<emeyer> …Because we’re only going forwards in the tree
<masonf> FYI, I'm here and I understand the group wanted to talk about 8189 but I wasn't here earlier. Here now!
<emeyer> bramus: It’s implied by the name, I think
<emeyer> …The end boundary element should be a following sibling of the start boundary element
<emeyer> …It could be you style all the siblings from a certain element down
<lea> +1 to @scope-sibling over @sibling-scope for the reason fantasai mentioned
<emeyer> fantasai: I would go with @scope-siblings rather than @sibling-scope so they sort together
<lea> also typing @scope would bring both up in autocomplete
<lea> q?
<emeyer> lea: I agree with Elika on the naming; they sort together, they autocomplete together
<emeyer> astearns: Should we resolve on that?
<emeyer> bramus: I’m fine with that
<fantasai> i/lea/bramus: Would it be @scope-sibling or @scope sibling?
<emeyer> astearns: We do tend to go with non-plural syntax for things, so @scope-sibling
<emeyer> fantasai: The non-plural form reads weirdly
<emeyer> astearns: Yeah, okay
<emeyer> miriam: You are creating a scope of siblings
<emeyer> florian: We do have precedent for a few plurals
<emeyer> RESOLVED: The name will be @scope-siblings
<emeyer> astearns: Anything else?
<emeyer> miriam: I think we’re hoping things will carry over from the other one
<emeyer> bramus: There’s another CSS cascade issue at the bottom of the list
<emeyer> astearns: People have joined specifically for the animation issue, so I want to do that next