[web-animations-1] [svg-2] Replacement for ShadowAnimation

[george-steel]

What do we do about SVG 2's ShadowAnimation interface now that the WebAnimations spec no longer provides KeyframeEffectReadOnly? Another problem is that with the specification of GroupEffect, an Animation no longer necessarily targets a single element, thus the original semantics of ShadowAnimation don't make sense as there is no single element to retarget.

One way to resolve would be to replace the ShadowAnimation interface by adding an affectsClones option to KeyframeEffect, which controls whether the animation also affects the target's clones in <svg:use/> shadow trees (clones are not webexposed due to closed shadow dom, thus we can't get their animations). For compatibility with current behavior, this defaults to true and it set to false when creating a CSSTransition or CSSAnimation.

[george-steel]

@stephenmcgruer @birtles @emilio What do you think?

[AmeliaBR]

One way to resolve would be to replace the ShadowAnimation interface by adding an affectsClones option to KeyframeEffect

This makes sense to me, would simplify things a lot.

[birtles]

I'm curious, are you implementing SMIL using Web Animations?

[george-steel]

I'm not sure, but the reason I ShadowAnimation is in the svg spec is specifically to handle script-created WebAnimations on cloned elements. What's your opinion on that use case?

[birtles]

I think that makes sense, but I wonder if there is any reason affectsClone would be false? Should it always just affect the clone(s)?

After all if you called commitStyles() it would update inline style on the element the spec seems pretty clear that, "these cloned element instances remain linked to the referenced source and reflect DOM mutations in the original".

I'm afraid I'm not familiar with the subtleties of the <use> and shadow DOM behavior so I'd defer to @emilio on what's best here.