[css-animations-1] @keyframes referencing from shadow roots does not match spec in any browser

[noamr]

In https://drafts.csswg.org/css-scoping-1/#shadow-names, it is specified that shadow names are inherited and can be used by descendant shadow roots.
However, in the case of @keyframes, no browser implements this. see https://css-names-in-the-shadow.glitch.me/anim.html, the 3rd row (inner element, outer keyframes), and despite appearing in the scoping spec, there is no mention of it in the css-animations spec.

Proposing to be explicit in the spec about current browser behavior, as changing all the implementations now might be too risky in terms of backwards compat? (If we changed all the implementations, what would probably happen is that things that didn't animate before due to an outer-scope @keyframes would now animate.

[noamr]

See screenshot of current state from all browsers:

[css-meeting-bot]

The CSS Working Group just discussed [css-animations-1] @keyframes referencing from shadow roots does not match spec in any browser, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<fantasai> noamr: Did research about how well we do ? on CSS names and shadow root
<fantasai> noamr: specified that names are inherited into a shadow root
<fantasai> noamr: so a name reference inside a shadow root can reference a name declared in an at-rule outside the shadow root
<kbabbitt> s/?/on interoperability/
<fantasai> noamr: I checked in practice what happens today, and nobody is spec-compliant
<fantasai> noamr: no interop, total mess
<fantasai> noamr: not a single at-rule that is both interoperable and spec-compliant
<fantasai> noamr: I wanted to raise attention to that
<fantasai> noamr: most of it we need to deal with implementation bugfixes
<fantasai> noamr: but for @Keyframes specifically...
<fantasai> noamr: outer element for outer keyframes plays animations
<fantasai> noamr: outer animations can't see inner keyframes
<fantasai> noamr: great
<fantasai> noamr: 3rd one is not spec compliant
<fantasai> noamr: inner element can't see outer keyframes
<fantasai> noamr: but that's the same in all browsers
<fantasai> noamr: inner element inner keyframes works in all browsers
<fantasai> noamr: ::part is totally broken
<fantasai> noamr: ::part() should be scoped to where the style for that part is declared
<fantasai> flackr: i.e. animation declaration decides scope of name lookup
<fantasai> noamr: I don't think there's ambiguity in the spec here
<emilio> q+
<keithamus> q+
<fantasai> noamr: but with #3, makes sense to spec what's implemented
<TabAtkins> q+
<fantasai> noamr: i.e. keyframe names aren't inherited into the shadow
<fantasai> noamr: need to match
<astearns> ack emilio
<fantasai> emilio: Another test to try, which is ::slotted()
<fantasai> emilio: I suspect that slotted element can see outside, but it can also be styled from inside
<fantasai> emilio: given this, I'm very skepi�tical that we'll have interop
<fantasai> emilio: wrt Firefox, what we do is generally look at animations in the scopes where the element would have picked style from
<fantasai> emilio: so that's why, for example, why ::part() inner keyframes would work in Firefox
<fantasai> emilio: so even though super messy on the surface, there's some logic to it
<flackr> q+
<fantasai> emilio: that's why i think ::part would behave differently if [missed]
<astearns> ack keithamus
<fantasai> keithamus: Pain point in web components community wrt styling slot
<emilio> s/::part/::slotted would behave differently than a "normal" light dom element
<fantasai> keithamus: there are several rules that should ideally follow principle of reverse scoping
<astearns> +1 to keithamus
<fantasai> keithamus: all the browsers should implement to the spec
<fantasai> keithamus: I know that may be difficult wrt priority of constitutencies but ...
<astearns> ack fantasai
<emilio> q+
<TabAtkins> fantasai: I suspect that the proposal to have ::part() behavior have a different scope available to the shadow is trickier than having them be conssitent
<TabAtkins> fantasai: so I suspect the right answer is to make the outer and inner scope available to the stuff in the shadow, regardless
<keithamus> s/difficult wrt priority of constitutencies/difficult, but I'd cite priority of constitutencies
<astearns> ack TabAtkins
<noamr> q+
<fantasai> TabAtkins: Support keithamus, inner element outer keyframes working is important
<fantasai> TabAtkins: ppl complain about this always
<emilio> TabAtkins: two things, inner element outer keyframes working is important
<emilio> ... the fact it doesn't work annoys everybody
<emilio> ... so that should work unless stuff break
<emilio> ... breaks
<emilio> ... re part, the reason why it's defined this way is because that's the styles the stylesheet has access to in all other contexts
<emilio> ... so having a part name a keyframe and have that intercepted by the shadow dom keyframe is potentially confusing
<emilio> ... that said it might be worthwhile making that confusion
<fantasai> 100%
<keithamus> +1; it also breaks encapsulation if light dom can use key frames from shadow dom.
<astearns> ack flackr
<emilio> ... So fine with either with either firefox or safari behavior matching spec, chrome behavior is terrible
<emilio> flackr: Mostly agree with tab
<emilio> ... one case gets complicated,
<emilio> ... what's the scope when you set the inline style
<emilio> ... FF has an answer to that question which is all the scopes that could much
<emilio> TabAtkins: per spec the style attribute is the same as a stylesheet in the element's tree
<emilio> ... the fact that you can have a ::part() read and set again is really weird
<emilio> ... I'm fine with the idea of name visibility being based on the element being styled
<emilio> flackr: fine with the weird behavior where it doesn't roundtrip through style too
<emilio> ... might be better for authors so you have the name based on the stylesheet apply the animation name
<astearns> ack emilio
<fantasai> emilio: was going to argue for "not Firefox behavior"
<fantasai> emilio: look at the element, not at the thing
<fantasai> emilio: because trivially implementable, don't need to track the source of the specific declaration
<fantasai> emilio: if doing a thing where we allow outer keyframes to match inner shadow tree, I'd rather define precisely the order of all the trees given an element
<fantasai> emilio: without looking at the stylesheet
<fantasai> emilio: but in the spec you need to check from which stylesheet the animation declaration comes from
<fantasai> TabAtkins: currently you start from tree and walk up
<fantasai> TabAtkins: [missed details]
<fantasai> emilio: shouldn't depend on the stylesheet the animation-name was specified
<fantasai> emilio: I think that's trivial to implement
<fantasai> emilio: given current mess, rather do that
<fantasai> TabAtkins: spoiler that makes it not trivial
<fantasai> TabAtkins: inherited values screw up
<fantasai> TabAtkins: because you don't want a font-family specified on an element in the light tree, inherit into shadow DOM
<fantasai> TabAtkins: that's what happened originally in WebKit's implementation
<fantasai> TabAtkins: caused accidental value change
<fantasai> TabAtkins: so you still need to track which tree a style was cascaded into
<fantasai> TabAtkins: and track it through inheritance
<fantasai> fantasai: I was assuming only talking about animation since non-inherited. Agreed for fonts it needs to be bound earlier
<fantasai> TabAtkins: nobody does good things, but spec doesn't separate out because the spec's current solution is reasonable for this case
<fantasai> emilio: should the font-face lookup be ??
<astearns> ack noamr
<fantasai> noamr: My suggestion to spec current behavior is jsut from perspective of not having specifiction
<fantasai> noamr: rather than finding a good solution
<fantasai> noamr: but happy to spec something else if we're actually going to do that
<fantasai> noamr: I'd like to see us fix this
<fantasai> noamr: We don't want to be leaky, so that's why Safari behavior is better
<fantasai> noamr: doesn't leak shadow DOM stuff external style
<fantasai> noamr: you want to animate a part in some way, and it does something internal
<fantasai> noamr: maybe thinking about names from inside... parts are specifically exposed but keyframes are not
<fantasai> TabAtkins: currently specced behavior gets you that
<fantasai> astearns: proposed resolution for this particular issue is to close no change ...?
<fantasai> noamr: but continue for fixing this on the web
<fantasai> astearns: and then continue discussing for parts/slots
<fantasai> RESOLVED: close no change

[kbabbitt]

Wanted to follow up and say thanks @noamr for collecting compat data on this! Your test page seems like a good candidate for a WPT, so I'd like to suggest turning it into one if you haven't already.

[noamr]

Wanted to follow up and say thanks @noamr for collecting compat data on this! Your test page seems like a good candidate for a WPT, so I'd like to suggest turning it into one if you haven't already.

I did not have time to turn it into a WPT (or a collection of WPTs), help is appreciated!