[css-nesting-1][css-cascade-6] Should/can relative selectors be allowed un-nested

[mirisuzanne]

@LeaVerou raised this question in a discussion about scoped imports:

why aren't they valid? We resolved a while ago that outside of nesting, :scope and & resolve to :root. If > h2 is essentially equivalent to & > h2, why wouldn't that be valid in the root scope?

[romainmenke]

This was previously discussed here: #8010

Maybe we should re-open that issue?

[tabatkins]

My arguments against top-level relative selectors only apply to actual top-level selectors, unscoped by anything. If you have a scoped stylesheet, they don't apply, and I think top-level relative selectors are fine. (Notably, non-relative selectors work as expected in that case, identical to non-relative selectors inside a @scope block.)

[mirisuzanne]

If we don't allow them generally, I think it would be strange to allow them when the same file is imported with a scope modifier. That would make the syntax conditionally valid depending how the file is imported. My preference would be to have the same rules in both cases.

Notably, if we disallow, authors can still achieve the same impact explicitly:

:scope > h2 { … }

As you noted in the other issue, when :scope is the root html element, both child and sibling combinators become basically useless. So this might only match when the stylesheet is scoped – but it would be valid and clear about the intent of the selector in both cases.

[tabatkins]

That would make the syntax conditionally valid depending how the file is imported. My preference would be to have the same rules in both cases.

Yeah, that's a reasonable argument to keep them banned here, and I agree that writing :scope > ... is reasonable and readable when it's necessary.

[LeaVerou]

I think it's pretty confusing if & behaves like :scope in some contexts and not others. What's the downside of letting it be valid regardless?

[mirisuzanne]

I don't think & ever behaves quite like :scope? & always refers to the parent selector (which might be the scoping selector, but could match multiple elements) while :scope refers to the scoping root element (always a single element).

[css-meeting-bot]

The CSS Working Group just discussed [css-nesting-1][css-cascade-6] Should/can relative selectors be allowed un-nested, and agreed to the following:

• RESOLVED: Close no change.

The full IRC log of that discussion

<fantasai> fantasai: Might've been useful to have Tab at this breakout
<fantasai> miriam: This was raised by Lea wrt if a whole file is scoped on import
<fantasai> miriam: If those items are relative selectors ...
<fantasai> miriam: Should we allow relative selectors at every level of CSS including the root?
<fantasai> miriam: If so, what would it mean?
<fantasai> miriam: My leaning is that we don't need to do this
<fantasai> miriam: Tab had some concerns with it
<fantasai> miriam: For example, a relative selector with a child combinator is meaningless in relation to the root
<fantasai> miriam: similarly ??
<fantasai> miriam: And normal descendant selector doesn't need to be relative until imported into a scope
<fantasai> miriam: So not really combinators that are meaningful to do at the root level
<andruud> q+
<astearns> ack andruud
<andruud> Just move on for a bit then
<astearns> ack fantasai
<emilio> scribe+
<emilio> fantasai: the child combinator [drop]
<matthieud> q+
<emilio> matthieud: what's the point of having relative top level selectors?
<emilio> ... if we allow these is it only working when we `@import` scope() something?
<emilio> miriam: leaverou was expecting it to be relative to `:root` by default, but as tab pointed out that's not particularly useful
<emilio> ... so that's why I suggest no-change
<emilio> ... once we import in scopes I think people may want to do it but I don't think it makes sense to make it valid or not depending on the way it's important
<kizu> +1 to no change
<emilio> matthieud: agree that they can just wrap in `:scope`
<emilio> miriam: or prefix each selector yeah
<emilio> fantasai: I think it's fine
<emilio> emilio: +1 fwiw
<emilio> astearns: if we're wrong and this is something people are going to use often
<emilio> ... and litter their sheets with `:scope`, how frustrating is that going to be?
<emilio> q+
<emilio> ack matthieud
<astearns> ack matthieud
<emilio> miriam: not sure who's going to complain about it
<emilio> ... but I think it's more explicit when you litter it with `:scope`
<emilio> ... so I think it's still the right choice
<emilio> ... it also raises the question of also allowing bare declarations in `@scope`, do we want to allow bare declarations in a css file?
<kizu> +1, explicit > implicit
<fantasai> emilio: You don't have to use :scope everywhere, right, can just wrap whole style sheet in @scope
<fantasai> emilio: so even if you wanted to do this, only need to add 2 lines of CSS ... and technically don't even need the closing bracket
<astearns> ack emilio
<emilio> s/@scope/:scope {`
<emilio> s/@scope/:scope {/
<fantasai> miriam: only needed for sibling or child combinator. Most styles are descedant combinators anyway
<fantasai> miriam: and sibling is out of scope
<fantasai> andruud: I'm happy with the discussion so far
<romain> +1 to no change
<emilio> +1
<fantasai> astearns: Proposed resolution, closed no change. Objections?
<fantasai> RESOLVED: Close no change.