[css-selectors] Allow relative selectors everywhere

[romainmenke]

A significant motivation behind changing the nesting syntax was making selectors easier to copy/paste between contexts.

• [css-nesting-1] Syntax Invites Errors #7834
• [selectors][css-nesting] Move nest-containing and nest-prefixed selector definitions to Selectors #5745

This changed .foo { & .bar{} } into .foo { .bar{} }
Both .foo and .bar can be copy/pasted to any other context, or could have been copy/pasted from any other context.

.foo { > .bar{} } however can not be copied to the root of the stylesheet.

/* invalid */
> .bar{}

Currently I think it is only allowed in :

• @scope
• nested context
• :has()

#7854 (comment)

Can > .bar{} be equal to :scope > .bar{} in all contexts?

All the pseudo's that accept selectors will need to be defined :

• :is(> .foo)
• :host(> .foo)
• ...

Maybe :scope is not suitable everywhere?

[Loirooriol]

A top-level style rule > .bar{} doesn't seem particularly clear to me.
But this can be convenient for element.querySelector("> .foo").

[romainmenke]

A top-level style rule > .bar{} doesn't seem particularly clear to me.

I agree, but I think this is also true for .foo { > .bar {} }
I prefer to have everything explicit as I think the resulting stylesheet is easier to maintain and understand (even for people who are not an expert in CSS).

But the current trend is clearly in favour of implicit and terse notations.

---

element.querySelector("> .foo")

I hadn't yet thought about querySelector and friends. Yes those already support :scope today and this would indeed be convenient.

Another one is @supports:

html {
	> body {
		color: red;
	}
}

@supports selector(> :possibly-invalid) {
	html {
		> :possibly-invalid {
			color: green;
		}
	}
}

html {
	@supports selector(> :possibly-invalid) {
		> :possibly-invalid {
			color: green;
		}
	}
}

These supports checks fails because relative selectors are not allowed there.
This can be confusing to authors.

[tabatkins]

I don't think we should support top-level relative selectors. It's not immediately clear what they're relative to. If you say "the root", then (a) virtually nothing will ever successfully match, so it doesn't seem useful, and (b) the behavior for "implicit descendant combinator" relatives will be different anyway, since they can match the root.

Hammering on (a) a little more, unless you're doing some DOM shenanigans, then neither of the sibling combinators will ever match, and the child combinator will only let you match the head and body elements which are, again ignoring DOM shenanigans, unique anyway and thus didn't really need nesting anyway.

[romainmenke]

(b) the behavior for "implicit descendant combinator" relatives will be different anyway, since they can match the root.

I think that is the best reason not to do this.

---

I mainly wanted to give this some thought because part of the reason to update the nesting specification was to facility copy/paste of selectors.

I don't think the updated specification fully succeeded in that goal but that is fine.

---

This issue can be closed unless someone wants to spend more time on this.
Thank you for the insights!

[tabatkins]

Yeah, given that the sole copy-paste scenario supported here would be from rules nested inside of html {...}, I don't think the loss is very meaningful in practice. ^_^

[Thaina]

Should it be possible to allow top down selector if it just have problem of circular dependency?

I mean, the child should allow access to its parent value, and below sibling should allow access to above one

I wish we could define stacking color by css function, to make a nested box that change bg to be darker than its parent scope. Stacking in itself will be darker recursively