Re: [csswg-drafts] [css-cascade-6] Is it possible to create a scoping boundary over sibling elements? (#7233)

Hi @romainmenke, it's an interesting use-case - and it does require something similar to scope. I find that really interesting to consider, but I think it needs a bit of disentangling the parts. The current scope spec has two aspects, and their use-cases overlap:

- 'scope' itself is mostly about limiting the range of elements that can be selected. That's handled with a root and boundaries.
- 'proximity' gives cascade priority to the selector with a 'closer' relationship between elements in the DOM.

As far as I can tell, your example would only need one of those two features. If you weight the proximity of siblings, you no longer need sibling-boundaries (the 'scope' part), and if you 'scope' the selectors to a particular range of siblings (implied by you suggested syntax), you no longer need the proximity weighting (since the scopes don't overlap).

In order to define sibling-based 'scopes', we would need a more major shift to the syntax. Currently, the 'root' selector is able to generate a scope based on the DOM tree that includes the root and all its descendants. Then the boundaries are scoped to that tree, narrowing it further, and nested selectors only match in the resulting subtree fragment. For a sibling-based version, the root selector would have to take on an entirely different meaning, returning potentially multiple sibling trees rather than a single descendant tree. I'm interested in thinking about that more - but it's such a major shift in the meaning of 'scope' that it would require significant re-imagining, and some explicit switch between the two modes.  

Proximity, on the other hand, would be much simpler to extend. The current spec includes a `>>` [descendant combinator](https://www.w3.org/TR/css-cascade-6/#scope-combinator) that applies proximity weighting based on a descendant relationship, without any 'scope' behavior. I could imagine a similar `~~` proximity-weighted sibling combinator that applies proximity to sibling relationships. Since combinators already describe the desired direction of the relationship (descendant or sibling), there would not be confusion about their meaning. So Then your example would look like:

```css
h1 ~~ p {
 color: red;
}

h2 ~~ p {
 color: green;
}

h3 ~~ p {
 color: blue;
}
```

That would achieve what you're going for in the example - but it does have a slightly different meaning than applying a boundary. The main difference is in what happens with styles that _don't conflict_. If we add a margin to the first selector block, it would apply to all paragraphs following the h1, and not only the paragraphs between h1 and another header.

**tldr;** there's a pretty clear path for applying _cascade proximity_ to sibling selectors if we want it, but it would take some significant re-imagining of the `@scope` syntax to apply 'sibling boundaries'. I'm intrigued by the idea, but I'm not sure how well it actually maps onto existing definitions of 'scope' as a tree fragment with a single scope-root.

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7233#issuecomment-1134984871 using your GitHub account


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

Received on Monday, 23 May 2022 18:10:56 UTC