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

[xiaochengh]

Ya ya yawm TAG!

I'm requesting a TAG review of CSS tree-scoped at-rule names and references (for @font-face, @Keyframes, etc.).

It has been a long standing issue on how name-defining at-rules (@font-face etc.) should be handled across shadow tree boundaries. The existing behaviors either break shadow tree encapsulation, or do not allow such at-rules in shadow trees at all. They are non-interoperable between browsers, and even inconsistent in the same browser between different rules.

Following a recent CSSWG resolution, a new and reasonable behavior has been proposed. Chromium is planning to implement this new behavior, starting with the @counter-style rule. So I'm requesting a TAG review of this new spec.

• Explainer (I think the examples in the spec are good enough to explain the new behavior):
  • https://drafts.csswg.org/css-scoping/#example-f1503361
  • https://drafts.csswg.org/css-scoping/#example-ee72cb37
• Specification URL: https://drafts.csswg.org/css-scoping/#shadow-names
• Tests:
  • https://wpt.fyi/results/css/css-counter-styles/counter-style-access-from-shadow-dom.html
  • https://wpt.fyi/results/css/css-counter-styles/counter-styles-override-in-shadow-dom.html
  • https://wpt.fyi/results/css/css-counter-styles/counter-style-fallbacks-in-shadow-dom.html
  • https://wpt.fyi/results/css/css-counter-styles/counter-styles-shadow-dom-part.html
• Security and Privacy self-review: I do not expect security/privacy risks
• Primary contacts (and their relationship to the specification):
  • Xiaocheng Hu (@xiaochengh), Google, Implementer
  • Tab Atkins (@tabatkins), Google, Spec Editor
• Organization(s)/project(s) driving the specification: CSSWG
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • [css-scoping] Handling global name-defining constructs in shadow trees w3c/csswg-drafts#1995
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/5716198446596096 (for @counter-style only)

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: August 12, 2021
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification: I'm not aware of any
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @xiaochengh

[tabatkins]

This is being requested for TAG feedback because it is a CSS-wide behavior change (well, behavior definition), and interacts with shadows and their information-hiding/componentization, so want to make sure we're not missing anything wrt platform consistency or other issues.

The examples Xiaocheng cites are indeed a great in-depth explanation of the behavior, but in short, the behavior is:

• Whenever a property references an at-rule by name, the keyword for the name is a "tree-scoped reference", and remembers what tree its stylesheet is in. When it needs to find the referenced at-rule, it looks in that tree specifically, even if it's been inherited or assigned to elements deeper in nested shadows.

  This ensures that components can't accidentally clash with at-rules defined outside of themselves, unintentionally changing the meaning of inherited or ::part()-inserted values. (Without this, a well-behaved component would have to give their at-rules UUID-ish names to have a high likelihood of avoiding clashes.)

• If a tree-scoped reference can't find the named at-rule in its remembered tree, it walks up the tree-of-trees to find the name in an ancestor scope. (Or, put another way, at-rules "inherit" down into shadows.)

  This mimics the implicit information-leakage that CSS already purposely allows with property inheritance, particularly inheritance of custom properties. It also means that a page can use in-house components that reference things like @font-faces it knows will exist in the outer document. Accidental clashes can only occur if a component is expecting this "inheritance" to work, but is nested inside of a foreign component that also uses the same name; this is the exact same failure scenario that custom properties have.

[torgo]

@xiaochengh from a multi-stakeholder PoV: from the linked discussion in CSS it looks like Firefox is also implementing. Can you confirm?

[LeaVerou]

Hi @xiaochengh @tabatkins!

We looked at this during the plenary today and overall we are happy with the direction this is going and think the proposed reference mechanism is intuitive.
However, we noticed that the linked resolution is tentative, has there been another resolution? If so, could you link to it?

[tabatkins]

It was only tentative in the sense that if we found any compat constraints due to existing wild behavior, we might need to capture that as a special case. As you can see from the partially-filled-in table at https://wiki.csswg.org/spec/css-scoping, there's zero agreement and a lot of cases simply don't work at all today, but the bits of behavior that do work are largely consistent with the resolved/specified behavior, so most code that works today should probably continue to work.

We haven't had a further resolution since that, since compact impact would need to be assessed to go further (and Chrome is gonna be the first to start implementing these behaviors).

[xiaochengh]

@torgo I've requested for Firefox's position here: mozilla/standards-positions#556

Right now they haven't confirmed yet

[hober]

We discussed this in our plenary session today, and overall we're really happy with where this has ended up in terms of the authoring experience. It would be hard to come up with a solution more intuitive to component authors. We note that this may have implementation complexity impact, so we encourage the WG to solicit implementor feedback from engineers familiar with the innards of each of the three engines.