CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.)

[xiaochengh]

Request for Mozilla Position on CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.)

• Specification Title: CSS Scoping / Name-Defining Constructs and Inheritance
• Specification or proposal URL: https://drafts.csswg.org/css-scoping/#shadow-names
• Bugzilla URL:
  • (For @keyframes) https://bugzilla.mozilla.org/show_bug.cgi?id=1458189
  • (For @font-face) https://bugzilla.mozilla.org/show_bug.cgi?id=1077396
  • (For @counter-style) https://bugzilla.mozilla.org/show_bug.cgi?id=1672302
• Mozillians who can provide input (optional): @emilio

Other information

Following a recent CSSWG resolution (https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-848941922), this section of the CSS Scoping Level 1 spec has been revised with an inheritance-like behavior introduced. Chrome is planning to implement the new behavior, starting with @counter-style.

[emilio]

So is the idea that we carry around the scope the rule comes from in the computed value in order to match the first initial tree?

As in if you style from a ::part() selector, we won't look into the shadow tree's scope, but we would if the shadow styles the part itself with the same counter style name?

[xiaochengh]

So is the idea that we carry around the scope the rule comes from in the computed value in order to match the first initial tree?

Yes, if this is what you mean by "match the first initial tree": When dereferencing such a scoped reference, we first search within the scoped carried by the rule; in case of a miss, we walk up the tree-of-trees and keep searching until a match is found (so that a rule defined in the light DOM can still be used by any shadow DOM, matching existing behaviors).

As in if you style from a ::part() selector, we won't look into the shadow tree's scope, but we would if the shadow styles the part itself with the same counter style name?

Yes