[css-shadow-parts-1] Does @keyframes rule match in ::parts()?

[TakayoshiKochi]

Context: https://crbug.com/724975
Spec: https://tabatkins.github.io/specs/css-shadow-parts/

Suppose we have the following style in document:

@keyframes test {
  to { transform: rotate(360deg); }
}

#host::part(label) {
  animation: test infinite 1s;
}

Does this work, or this should not work?
Specifically, will animation: test apply to the ::part(label)?

In today's Blink implementation, it does not.
For pseudo elements implemented inside UA shadow (e.g. ::-webkit-slider-thumb, or input::placeholder), as the keyframe rule name lookup is scoped, and the selector and the element are in the different trees, test keyframe rule name lookup fails and thus the animation will not be applied.

For these elements, which are implemented within UA shadow DOM, it is just an implementation detail and maybe Blink should apply the test keyframe rule to those, but for ::part(), the actual element would be in shadow DOM, and clarification is needed.

[tabatkins]

How name-defining at-rules work with shadow trees is a long-standing issue, and is not currently defined. It sounds like Blink currently only looks for names defined in the same shadow tree?

How does it handle font names?

[TakayoshiKochi]

For @font-face, Blink treats the definition global, which is different from @keyframes.

There was discussions twice in www-style:
https://lists.w3.org/Archives/Public/www-style/2014Feb/thread.html#msg480
https://lists.w3.org/Archives/Public/www-style/2015Nov/thread.html#msg163
and crbug:
https://bugs.chromium.org/p/chromium/issues/detail?id=336876

The current conclusion is to leave @font-face global as is.

[tabatkins]

I just wrote up a proposal to solve this in #1995

[birtles]

It might be worth checking if #1995 covers the concerns @bzbarsky previously raised about the behavior of @keyframes and inheritance of animation-name in shadow DOM being under-specified: https://bugzilla.mozilla.org/show_bug.cgi?id=1018269#c7

Also, I know we agreed at one point that @keyframes should cascade (or at least I think that's what Tab's mail was aiming at) but I don't think anyone implemented that. And I suppose if we still want to do that we'd need to define how that works across shadow DOM boundaries.

[tabatkins]

It might be worth checking if #1995 covers the concerns @bzbarsky previously raised about the behavior of @Keyframes and inheritance of animation-name in shadow DOM being under-specified: bugzilla.mozilla.org/show_bug.cgi?id=1018269#c7

Yes, it does. Specifically:

Say the shadow host has style="animation-name: foo" and a node in the shadow DOM does style="animation-name: inherit". Say both the page and the shadow DOM have @Keyframes rules with animations named "foo". Which animation, if any, happens on the node in the shadow DOM and why.

Per my proposal, any reference to an externally-defined name is implicitly a reference to some defining scope as well, and scoped references automatically increment their integer when inheriting thru a shadow boundary.

This particular example is easy - my proposal defines that plain keywords are references to the global scope only, so the inherited value also refers only to the global scope. But say the shadow host was using animation-name: scoped(foo); to refer to the local @Keyframes animation, defined in the same tree as it; then the node in the shadow tree would implicitly have inherited a scoped(foo, 1) value, and also be referring to the @Keyframes in the parent tree, not its own.

[csvn]

I just encountered this issue while experimenting with Shadow Parts (https://jsfiddle.net/6dqm5oLr/1/). Now that I've read your discussions, it makes sense why it does not work, since the @keyframes declaration is not in the same scope (Shadow root). This is not a huge issue for my potential use case though, since it should be possible to use <slot> instead for the use cases where animation is really needed.

[lentschi]

I just encountered this issue while experimenting with Shadow Parts (https://jsfiddle.net/6dqm5oLr/1/). Now that I've read your discussions, it makes sense why it does not work, since the @keyframes declaration is not in the same scope (Shadow root). This is not a huge issue for my potential use case though, since it should be possible to use <slot> instead for the use cases where animation is really needed.

Just so I understand this correctly - You're saying that without changing the actual HTML/javascript in your fiddle, it's currently impossible to use @keyframes on the "Shadow Part title"? (I tried moving the @keyframes into the ::part(title) but that didn't help)

[csvn]

@lentschi from the above thread:

• @keyframes is not inherited into shadow-roots from global scopes
• @font-face for instance is inherited into shadow-roots (you don't need to re-import new fonts inside shadow-roots)

What this means is that my fiddle is not working, since inside the shadow-root there is no @keyframes with the name colors. So yes, my example does not work unless you e.g. copy the @keyframes into the <template> for the shadow-root: https://jsfiddle.net/srzv35cm/.

[tabatkins]

Per spec, both of those should "inherit" into shadow roots; it's just browser bugs that they don't.

[AdaRoseCannon]

Per spec, both of those should "inherit" into shadow roots; it's just browser bugs that they don't.

Are there browser bug issues for support of this?

I think the bug listed in the header isn't for that particular issue.

[AdaRoseCannon]

I found one for Gecko which seems fixed (I haven’t confirmed yet)

Couldn’t find one for Blink so I’ll make one.

Edit: Bug opened for Blink https://bugs.chromium.org/p/chromium/issues/detail?id=1398023
Confirmed not fixed in Gecko issue, existing issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1458189