Undefined specification for @keyframe scope on slotted content

[ruphin]

The specification is missing a definition for the behaviour of @keyframe scoping for slotted content. As a result, the two major implementing browsers (Chrome and Safari) show different behaviours.

Unspecified behaviour

When an animation is defined on a slotted element like so:

  ::slotted(div) {
    animation-name: some-animation;
  }

There is no specification that clarifies in which scope the @keyframes lookup takes place. (inside the ShadowRoot, or in the scope of the slotted component, in this case the <div>)

Possible resolutions

The lookup takes place inside the scope of the ShadowRoot where the element is slotted.

I consider this the expected behaviour, since the @keyframes lookup takes place in the same scope where the animation-name is defined in CSS.

Safari implements this resolution.

The lookup takes place inside the scope where the element is defined.

I consider this unexpected behaviour. It forces Web Component authors to 'leak' animation definitions outside the ShadowRoot in order to animate slotted content.

Chrome implements this resolution

Reproduction

A reproduction can be found here: https://codepen.io/ruphin/pen/zPQvXw
The animations you see on that page will differ depending on if you are using Safari or Chrome to view the page.

[annevk]

cc @tabatkins

[TakayoshiKochi]

Shall this be upstreamed to a relevant CSS spec?

[tabatkins]

This was brought up a few months ago, in w3c/csswg-drafts#1516 (and several times in the years prior). I wrote up a proposed solution in w3c/csswg-drafts#1995, but nobody's bitten on the thread. Happy to drive it if anyone's interested, tho.

Short form of the proposal:

• name-defining rules are visible to the scope they're defined in, and all scopes descending from that.
• referring to a name-defining rule with an ordinary keyword (like animation-name: foo; always refers to the "global" version defined in the top-level page.
• alternately, you can use scoped(<keyword>) to refer to the "local" version, defined in your shadow tree
• you can also use scoped(<keyword>, N) to refer to the local version N tree scopes up (or in the global scope if there aren't enough intervening scopes). This allows inheritance to work across shadow boundaries while still allowing every value to be written down. This form generally shouldn't be used manually, as it's fragile, but it existing makes the mechanics of the proposal work better.

[ruphin]

I left a comment on w3c/csswg-drafts#1995 - seems like that is the right place to move this discussion.

[annevk]

Indeed. The README of this repository now hints at that more clearly. Suggestions for more improvements to our README welcome.