Re: [w3ctag/design-reviews] Early design review of light-DOM CSS Scope proposal (#593)

> I've also had some conversations with @tabatkins about using aspects of the [nesting syntax](https://drafts.csswg.org/css-nesting/) here, like the `&` nesting-selector. I'll add a section about that approach to the proposal.

If you use `&` to refer to the scope root, authors in nested rules would not be able to refer to the nesting root and the scope root separately. I think `:scope` was perfectly suitable here.

> I've done some work on this, but struggled to find a selector approach that makes sense to me. I'll try and document my thoughts on that a bit more, but if you have ideas, I'm interested.

A few raw thoughts on this:

Essentially the scope targeted by `@scope (.a) to (.c)` are elements that match `.a` or `.a *` except those that are also `.c` or contained in it. E.g. in the subtree below:

```html
1 <div class="a">
2  <div class="b">
3    <div class="c">
4     <div class="a">
5      <div class="b">
6        <div class="c">
```

It would be the elements in lines 1, 2, 4, 5.
If we could not have nesting of these donuts, this *could* have been expressed as `:is(.a, .a *):not(.c, .c *)`, but given the nesting above, that would fail (it would select 1, 2 but not 4, 5). This makes me wonder if a pseudo-class would be the right approach, e.g. `:donut(.a / .c)` (name ridiculous on purpose to be bikeshedded). Why not `.a:to(.c)`? I think simple selectors need to be independent, and it's their intersection that produces the match of a compound selector (hence why `:nth-match()` needs to take its selector as an argument and not just follow it).

At first I thought a combinator makes more sense, but since the rightmost operand needs to match the selector target, that wouldn't work for specifying the lower boundary.

Aside: What does `@scope (S) to (S)` match, where S is any selector? Does it match nothing?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/593#issuecomment-769351277