[css-animations-2] interaction between the `timeline` property and `animation-timeline` property

[graouts]

CSS Animations Level 2 has a section detailing how setting properties via the Web Animations APIs can override related CSS properties. For instance:

After a successful call to play() or pause() on a CSSAnimation, any subsequent change to the animation-play-state will no longer cause the CSSAnimation to be played or paused as defined in § 4.5 The animation-play-state property.

This section makes no mention of setting the timeline property of an animation. I believe the spec should detail what happens when setting animation-timeline after the timeline property has been modified via the JS bindings.

Additionally, should setting the effect property have any effect on further changes to the animation-timeline property? Currently, the spec says so:

After successfully setting the effect of a CSSAnimation to null or some AnimationEffect other than the original KeyframeEffect, all subsequent changes to animation properties other than animation-name or animation-play-state will not be reflected in that animation. Similarly, any change to matching @keyframes rules will not be reflected in that animation. However, if the last matching @keyframes rule is removed the animation must still be canceled.

But the timeline being a property of the animation, and not the effect, should animation-timeline be excluded here?

[graouts]

Cc @birtles, @flackr, @andruud and @kevers-google.

[graouts]

WebKit is making a change via in its implementation via https://github.com/WebKit/WebKit/pull/35513 such that setting timeline via the JS property will make any further change to animation-timeline not affect the timeline set on the animation. However setting effect will not interfere.

[ydaniv]

+1 to both

[flackr]

Thanks for calling this out, this was an oversight. I agree with both choices.

[ydaniv]

@flackr can we resolve on this one async?

[ydaniv]

@graouts was this done via #11812 ?

[graouts]

@graouts was this done via #11812 ?

I believe that is correct! If @birtles or @flackr agree as well, I believe we can close this.

[flackr]

Agreed, I don't think we need a resolution, this falls within the realm of behavior that was always intended, but overlooked in the spec text.