[css-cascade-6] Can we support implicit scopes in nested settings?

[mirisuzanne]

We have previously resolved to supply an 'implicit' scope-root inside <style>. The root is the parent node of the <style> element:

<article id="my-thing">
  <style>@scope { /* similar to `@scope (article#my-thing)` */ }</style>
</article>

A different implicit scope-root might be more useful when @scope is nested inside other selectors. In that case, I would expect the missing (<scope-start>) should default to (&):

article {
  /* un-scoped `article` declarations */

  @scope { /* same as `@scope (&)` */ }
  @scope to (.another-thing) { /* @scope (&) to (.another-thing) */ }
}

That isn't exactly a parallel behavior, and I'm not sure if there are edge cases where it might be unclear which is intended. But I think this would be the most useful/expected result from a nested @scope syntax.

[andruud]

I think it makes sense. But since it's a breaking change, we'd ideally have a use-counter before making a decision.

[mirisuzanne]

@andruud could you start running that use-counter now, or should we get a resolution in advance? It seems like there's positive interest in this, and it would be worth taking to the group if we can.

[andruud]

should we get a resolution in advance

Yeah, I didn't manage to get a use-counter going yet, so let's get a resolution in advance. Given that the usage for @scope in general is still very low, and this change only applies to @scope as a nested group rule, I'm fairly confident that a narrower use-counter will show an acceptable number.

Also, it appears that @scope will soon be supported in all browsers, so we shouldn't wait much longer with this change.

[tabatkins]

And this should presumably use the same "same set of elements as the parent" semantic that implicit nested rules get (like .foo::before { @media (...) { color: red; } }), so pseudo-elements work properly. (Rather than literally using &, which doesn't work with pseudo-elements currently.)

[andruud]

@tabatkins I don't think that makes sense.

• A @scope rule selects a specific element to become the scoping root.
• A CSSNestedDeclarations rule within @scope then matches that scoping root with zero specificity, (equivalent to :where(:scope)). https://github.com/w3c/csswg-drafts/issues/10431
• Pseudo-elements can't be scoping roots, and I don't think we should change that. https://drafts.csswg.org/css-cascade-6/#scope-syntax. It is a separate issue in any case.

So I think & is fine here.

[tabatkins]

Hm, ok. I don't want to rely on pseudo-elements never being scoping roots, but if that's currently the case then the difference would be unobservable anyway.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-6] Can we support implicit scopes in nested settings?, and agreed to the following:

• RESOLVED: close this issue, no change unless better arguments

The full IRC log of that discussion

<dbaron> ScribeNick: matthieud
<matthieud> miriam: previously we creating implicit @scope root without a prelude-start
<matthieud> miriam: the parent node is the implied scoping root
<matthieud> do we want to have the similar implicit behavior in a style rule nested context ?
<ydaniv> q+
<astearns> ack ydaniv
<matthieud> ydaniv: what if it's not nested ?
<matthieud> miriam: we allow non nested & selector which resolve to root, could be the same
<astearns> ack fantasai
<matthieud> fantasai: when no scope-start, it uses the closest node at the scoping root
<matthieud> fantasai: with this resolution, we will longer be able to reference this implicit scoping root
<fantasai> s/longer/no longer/
<matthieud> miriam: the confusion is if you are in a style element in the doc, with an implicit @scope non nested and one nested inside a style rule, they don't have the same scoping root anymore which could be surprising
<ydaniv> q+
<fantasai> Example is
<matthieud> ydaniv: it's useful to have this functionality
<fantasai> <section><style>@scope { ... }</style> ...</section> vs <section><style>@style (&) { ... }</style> ...</section.
<matthieud> miriam: there is no way to get back the parent node if we adopt this resolution
<matthieud> ydaniv: we could have a new keyword
<matthieud> fantasai: there are other situation where & and :scope don't represent the same element
<fantasai> s/fantasai/miriam/
<matthieud> PROPOSED SOLUTION: close this issue, no change unless better arguments
<matthieud> RESOLVED: close this issue, no change unless better arguments
<fantasai> s/better arguments/arguments for stronger than those against/