[web-animations-2] Setting the timeline to null during play vs. play-pending

[andruud]

The algorithm for setting the timeline of an animation confuses me. When setting the timeline from DocumentTimeline to null, we get different results if we have a pending play task, vs. if we're actually playing. My (potentially inaccurate) iterpretation is this:

• If we set the timeline to null during pending play, we get a resolved hold time (and hence current time) stuck at zero.
• If we set the timeline to null during actual play, we get some resolved start time and an unresolved hold time, hence per current time of an animation we get an unresolved current time, since we have no timeline.

1. Isn't it weird that we get a resolved current time with a null timeline? (Pending-play case).

2. What is supposed to happen for CSS animations?

@keyframes anim {
  from { width: 100px; }
  to { width: 200px; }
}

#div {
  width: 0px;
  animation: anim 1e10s linear;
}

// Initially document.timeline.
getComputedStyle(div).width; // 100px;
div.style.animationTimeline = 'none';
getComputedStyle(div).width; // ???

The result can not depend on pending-play status.

cc @kevers-google

[kevers-google]

The chrome implementation does not actually call the web-animations-2 procedure for setting the timeline when the timeline is updated via a style change rather than an API call (it probably should). Having said that, when updated via animation.timeline = ... we do see a difference in the result. While in the play pending state, the hold time and current time are both zero. When the timeline is changed after the ready promise resolves, we have a resolved start time, unresolved hold time and unresolved current time. The change in the value of current time results in getComputedStyle returning either the initial state of the animation or the underlying value of the property. Note that if the timeline were initially null, we would be stuck in a play pending state as we would not resolve the ready promise.

Resetting the timeline, either via a style change or API call, should likely be consistent with current time becoming null due to a scroll timeline becoming inactive. The complications with scroll timelines are discussed at length here:

https://github.com/w3c/csswg-drafts/issues/2066

This discussion does not fully address this issue, but provides some useful background information and has some directly relevant comments.

[BorisChiou]

This may makes this wpt unreliable because in Gecko the "[immediate]" test case is during play-pending, and the "[scroll]" test case is during play. I also agree that the result can not depend on pending-play status.

[flackr]

Setting the timeline of a pending animation in general shouldn't remove the pending play task as the animation's start time will now depend on the new timeline. Setting the timeline to null should be similar to setting a resolved start time since we know that the animation is not going to start, i.e. it should cancel any the pending play task and perhaps reject the finish promise similar to calling cancel on the animation. The only way a null timeline animation should have a hold time and product an active effect is if it was paused.

Your demo should result in getComputedStyle(div).width returning 0px with the animation being considered inactive, regardless of timing.