Re: [csswg-drafts] [css-nesting-1] Name, terminology, and nesting selector misnomers are footguns (solution proposed) (#8329)

> This syntax defines how style rules are nested into other style rules; calling the spec "Nesting" works just fine, and there's not really anything that it's ambiguous with.

Except it's not really a style rule inside a style rule, is it? It's a shorthand for an at-rule, and the nesting this is defining doesn't apply to other specs using their version of nesting. It's a conflict to call them all nesting while defining only one of them as nesting that works in a unique way.

> It matches one of the scoping elements from the nearest `@scope` (the outer one, since you're in the middle of defining the inner one).
> It matches one of the scoping elements from the nearest `@scope`.

But with `:scope` allowed in any position? If so, it's already doing what I suggest, just not explicitly indicated as such. If not, then that's unnecessarily limiting `:scope` to the start a selector only.

> Indeed they're not, `:scope` and `&` do essentially the same thing, and that's part of the issue - if we used `:scope` for both, and an author uses the two features together, they could only refer to one or the other. In particular, they wouldn't be able to use `@scope (.one) { .two { :scope.three * {...}}}` to style things where the scoping element has both `.one` and `.three`; their selector would instead be referring to a `.two.three` element _underneath_ the scoping element, as the `:scope` refers to the intervening style rule rather than the scope rule.

Why would you need to use them together in that way? If the use of each is creating a new scope, you would just write and nest your selectors and scopes accordingly.

Unless I'm misunderstanding, as it currently stands, your example would be `:is(.one) :is(.two) :is(.one).three *`. In what I'm suggesting, it would become `:is(.one) :is(.two).three *`. Neither achieve what you want, but your example is a confusing way to attempt that, so I'm not entirely sure what you wanted to target. In my suggestion something like `@scope (.one) {  .two {...} :scope.three * {...}}` would work (even `@scope (.one,.three) { * {...}}` seems sensible, but not part of the spec).

> [...] but a `@scope` rule _does_ generally represent a more semantically meaningful container than a nesting rule does, so the chance that you'll want to refer to it is higher.

Except if nesting was scoping, they have the same semantic meaning. I'd also argue being meaningful is both situational and not the important factor for referring to it later, as a unique scope is less likely to be reused than one that could match multiple times as in nesting (i.e. the same scope matching inside that scope).

> Nesting does not act like a scoping container. It's very much normal to write nested rules that aren't _remotely_ scoped to the outer rule, like `.foo { :not(&) {...}}`, not to mention using sibling combinators, etc.

How is that not scoped? A limited scope should not be seen as the only way to use `:scope` or create new scopes from existing scopes.

I said scoping limits (a behaviour not part of `:scope` itself) would need to be considered, but didn't elaborate on that as to how it might change. Currently scoping is done strictly as a scoping limit, so you can't end up with an element outside the outer-most scope. Nesting would not want that in some cases, as there can be a desire to create new scopes related to the outer scope but not necessarily inside the scope, as you said.

- Does that need an entirely new spec, terminology and syntax? Not in my opinion.
- Does it need a modified or different at-rule for when those cases when nested inside `@scope` and wanting to reach outside it? Perhaps (but still not `@nest`).
- Could it be better written with nesting outside the limiting `@scope` anyway? Most likely.



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


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

Received on Wednesday, 25 January 2023 19:41:54 UTC