Re: [csswg-drafts] [css-nesting-1] Yet another nesting proposal (Option 5) (#7970)

I think @romainmenke is very likely right about predicting the poll result. But I guess we'll see. 

I very much appreciate having various alternative proposals to consider, and have backed several of them at this point. But I disagree with the premise mentioned a few times that some proposals are more 'programmer focused' while others are more appropriate for a broad CSS audience. So far all the seriously-considered proposals have been designed around CSS syntax, and they have all involved awkward tradeoffs that authors will need to get used to. This isn't a philosophical debate about the soul of CSS, it's a practical debate about how to make nesting work around some inconvenient parsing limitations.

Anyway, I want to follow-up a little on my mention of `@scope` on the call. I said I wasn't sure if that's a pro or a con for this proposal, but I don't think that's actually the right framing. More important than that, it brings into clearer focus how these features overlap, and where they differ. That's a pro for the discussion, no matter where we land.

## The overlap between `@scope` and `@nest` (version 5)

Like I said, the outline of this proposal (v5!) has a nearly identical footprint to the `@scope` feature as specified. These would select exactly the same elements:

```css
@nest foo {
    & { color: blue; }
    bar { color: red; }
}

@scope (foo) {
    & { color: blue; }
    bar { color: red; }
}
```

## The differences

There's only one difference between the selectors above, and that's _scope proximity_ - which gives some cascade priority to scoped selectors that have a 'closer' scope root. It's not clear at this point _how much_ of a difference that creates, because the spec is currently indecisive on _how much priority_ scope proximity should have (@fantasai and I drafted the spec, and we disagree on that point). From my perspective a _weak scope proximity_ (weaker than specificity in the cascade) would be a _desirable_ addition to nesting. The difference is subtle, but meaningful to authors. If we went that rout, the two features have a very large overlap.

But it's not a complete overlap, as we can see by looking at one of the other demos in the original post. The `@scope` rule _only targets elements that are inside the scope root_ (inclusive of the root element itself). So any nested rules that aren't truly nested may be an issue:

```css
@nest foo {
  + baz { /* sibling selector should work here, and match foo + baz */ }
}

@scope (foo) {
  + baz { /* since baz is a sibling of the scope root, it is outside the scope and not matched */ }
}
```

That's a pretty big distinction.

## Can we disentangle these features?

It seems to me like:

- In most (all?) cases where you want to select a truly nested element, `@scope` might be the better alternative. That's exactly what it's designed for.
- Most (but sadly not all) of the problematic edge cases for other nesting proposals fall into that category.

These problem cases for proposal 3 can all be represented in `@scope` without issues - because they target elements that are in scope:

```css
foo {
  baz { /*…*/ }
  html & { /*…*/ }
  baz + & { /*…*/ }
}

@scope (foo) {
  baz { /*…*/ }
  html & { /*…*/ }
  baz + & { /*…*/ }
}
```

My thesis here is roughly that `@scope` would help _limit the frequency_ of problematic use-cases. And it will do that in a way that matches this proposal pretty closely. 

Sadly for my thesis, it's not quite _all_ the problematic cases. These can't be converted to scope, because the targets are not nested:

```css
foo {
  baz:has(&) { /*…*/ }
  baz > & + bing { /*…*/ }
}
```

I don't feel like that's a conclusive argument. But, I think the main takeaway here is that we need to keep thinking of these features as intertwined. Specifically, the implementation of scope might change what people need or want from nesting.

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


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

Received on Wednesday, 30 November 2022 21:02:31 UTC