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

> No, that was an earlier version of the spec. There is no at-rule anymore in the current spec.

It may not exist anymore, but I guess I will always implicitly see the short-hand version is really that.
 
> The `:scope` pseudo-class can appear anywhere in the selector (of style rules inside of `@scope`). The elements matched by that selector have to be the scoping root or one of its descendants, due to being "scoped", but any other components of the selector can match anything in the tree. For example, `@scope (div.foo) { :root.bar p {...}}` will match `p` elements inside a `div.foo` element _if_ the root element (which is definitely outside the scope) has a `.bar` class. There's no implicit prepending of `:scope` to anything; the selectors are evaluated against the whole page, and then we just filter the results according to the scope.

Thanks, I understand what you're saying now. I still think that needs explaining more far more clearly in the spec, especially with examples of `:scope` being used in such a way. I can also see why that isn't going to be compatible in the way I described now, though not necessarily because this is not scoping as per the wider meaning point.

I do remain unclear about multiple uses of `:scope`, as do I with `&`. These both refer to the elements matched by a selector, not the selector, so should never work (afaik), but nesting at least seems to break that meaning by showing examples of desugaring them to the parent selector instead (just like selector inheritance, which it's not supposed to be). Is that outdate and/or a mistake?

> `querySelector()` doesn't use it
What if it did use it, even if with a different selector than `:scope` or options that nesting could use? It's something I'd like to see. It would simplify several lines of code for filtering (right now it can't return the `:scope` element itself, for whatever reasoning that was thought to not be allowed, so this can't be done for only filtering on ancestors) and traversing the tree. I don't see any other spec making that usage possible.

> [...] being able to refer to element outside your scope is just too useful of an ability to throw away.

Not sure what you mean here? Both allow referring to elements outside the scope, but match to an element outside the scope in what `@scope` is using.

> Nesting doesn't use it either - it does something _vaguely similar_ but still very distinct, allowing the selector to match _anything on the page_ with no required relation to the parent selector (if you write your selector accordingly).

I don't see the no relation (including your `:not(&)` example, as that's still a relationship) idea, so maybe that's why I don't see the distinction your see here? "Relative selectors" seems to be the terminology being used, which to me is a relationship to the parent selector. Even in the case of "non-relative selectors" with a nested selector, they actually are relative selectors (in plain language), but with a different relationship to the parent selector (even if exclusionary). So could you elaborate for me (assuming the broader meaning of scoping)?

I still think it's wrong to call this spec nesting while other specs use the term with a more general meaning that doesn't need defining (clearly showing css-nesting-1 is the odd one out here). Yes the rules are nested, it's more direct than others due to not needing selectors in the body to achieve it, and the spec leads with those things, but there's then the other at-rules that lead to nesting of rules without having relevance to the nesting of this spec. The rest of it is not specifically about the nesting, but about a way of creating a context for relative selectors that allows this type of nesting to work. That last part should be the focus and source of the naming.

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


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

Received on Thursday, 26 January 2023 02:26:46 UTC