[scroll-animations] Limit start time of progress-based finite timeline linked animations to 0

[ogerchikov]

Problem

In attempt to maintain web animations spec unmodified to support scroll animations, we introduced behaviors that are hard to rationalize. Specifically web animation APIs, such as setting current time, playback rate or unpause, adjust animation start time with a goal to preserve animation current time. This works fine for time based animations since the time is unlimited. The situation is different for scroll, or, as suggested by #4862, progress linked animations. Changing start time of such animations disconnects their progress from the progress of timeline. Observed behavior in these situations is that effect progress is out of sync with scroll and effect range is not fully accomplished.

In addition, the need to preserve start time significantly complicates specing for handling inactive timelines (#2066).

#2075 provides math for calculating start time and potential solutions.

Proposal

Limit start time of progress-based finite timeline linked animations to 0.

This involves disallowing changing currentTime, startTime of playing animations, only the currentTime of paused animations can be changed. Behaviors such as unpause or setting playback rate will cause a jump to the animation effect to stay in sync with the timeline progress.

To accept this proposal we need answers to these questions:

• Are there any use cases that require start time to be other than 0. I cannot think of any.
• Is it required to keep spec compat with time linked animations in how start time is updated in various procedures. Note, we already initialize start time to zero in Play procedure for scroll animations ([web-animations-1] Don't preserve current time for scroll linked animations when changing playbackRate #2075).

[ogerchikov]

Here is a chart showing progress linked animations state:

source

[ogerchikov]

@majido @birtles - can you please comment on this proposal?

[birtles]

My thinking on this is still basically this: #2066 (comment)

That is, it still seems a bit inconsistent to me to restrict startTime to zero.

[birtles]

The state chart does look nice and simple, however.

[majido]

@ogerchikov I believe per our last F2F sync, there is no more work needed on this issue given your changes to web-animations specification.

In particular you also verified that the currently spec'd behavior is also consistent with assigning time while animation has a null timeline and then changing the timeline which was my only remaining cocern.

[ogerchikov]

#4842 has spec changes required to handle inactive scroll timelines. Proposal in this issue is not required for scroll timelines.