Open andruud opened 5 months ago
Keeping scope consistent, I think we would use :where(:scope) {}
, so the resulting specificity is 0,0,1. The only specificity comes from the div
.
@mirisuzanne But the innermost rules would get 0,0,0 if we use :where(:scope){}
, not 0,0,1. The innermost rules do not "see" the outer div
rule. The thing that maintains a connection between div
and the innermost rules is the intermediate <scope-start>
selector, which gets an implicit &
prepended. Inner :scope
selectors then match the scoping roots created by that <scope-start>
.
oh, you're right - the result is more like :where(div #foo)
rather than div :where(#foo)
.
Huh, we should likely discuss these two issues together in the group. I think the logic makes good sense at every point along the way, but the zero-specificity result for bare declarations is still a bit surprising. Maybe a fine and reasonable result? But something we should clearly state, and demonstrate in examples.
Agenda+ to discuss along with #10389 and #9621
The proposal here is to treat directly-nested declarations in a scope rule such that:
:scope
elementThat is, as though the declarations are wrapped in :where(:scope) { /* declarations */ }
:scope
wrapper on scope-nested rules should not impact specificity. Which requires us to revert/clarify how that implicit :scope
is serialized (https://github.com/w3c/csswg-drafts/issues/9621#issuecomment-1864891688)I would like to resolve all three aspects of this at once if we can:
@scope
:scope
element, without additional specificity:scope
, so no implicit specificity is addedThe CSS Working Group just discussed [css-cascade] @scope as a nested grouping rule and CSSNestedDeclarations
, and agreed to the following:
RESOLVED: bare declarations in a scoped rule apply to the scoped root and add no specificity.
This came up when discussing #10389:
It is currently possible to place bare declarations directly in a
@scope
rule if it's a nested grouping rule:I think current WPTs (which haven't yet picked up #10234, nor the
@nest
edit which came before it) require the above to desugar to:(I think per specs that should strictly have been wrapped in a
&{}
actually, but I apparently forgot to raise an issue for this).As of #10234, I believe we now intend to desugar to:
Where the
CSSNestedDeclarations
rules match whatever#foo
matches (but within the scope, obviously), and with ... the same specificity as#foo
? It's this specificity part I'm not sure about, as it doesn't seem consistent with how "implied stuff" in@scope
is intended to work. For example, the#bar
selector effectively gets an implied:where(:scope)
selector prepended (#10196), which adds no specificity.So I wonder if we should specify that
CSSNestedDeclarations
rules, when the appear directly beneath@scope
, should act as:scope {}
or:where(:scope) {}
rules? (@mirisuzanne)