[web-animations-2] [scroll-animations-1] Auto-aligning the start time of an animation associated with a scroll timeline

[graouts]

I'm working on implementing Scroll-driven Animations in WebKit and having some trouble understanding how the start time of an animation associated with a scroll timeline ever gets resolved.

From my understanding, the start time of such an animation is set by the auto-aligning the start time procedure. Per HTML Processing Model: Event loop:

When updating timeline current time, the start time of any attached animation is conditionally updated. For each attached animation, run the procedure for calculating an auto-aligned start time.

So each time animations are updating, we have a chance to auto-align the start time of scroll-driven animations. But, the auto-aligning the start time procedure step 3 says:

If play state is idle, abort this procedure.

The play state is idle when:

All of the following conditions are true:

• The current time of animation is unresolved, and
• the start time of animation is unresolved, and
• animation does not have either a pending play task or a pending pause task,

My assumption is that the start time is unresolved since we're yet to set it via the auto-align the start time procedure. We do not have any pending tasks since when initially playing that scroll-driven animation, we aborted the play procedure after step 10:

If the following three conditions are all satisfied:

• animation’s hold time is unresolved, and
• aborted pause is false, and
• animation does not have a pending playback rate,

abort this procedure.

And the current time is unresolved precisely we don't yet have a start time and return unresolved in this step of the calculating the current time of an animation procedure:

If any of the following are true:

• the animation has no associated timeline, or
• the associated timeline is inactive, or
• the animation’s start time is unresolved,

The current time is an unresolved time value.

Therefore it is unclear to me when an animation associated with a scroll timeline can ever have a resolved start time or current time. What am I missing?

[graouts]

Cc @andruud, @flackr and @kevers-google (and apologies for initially assigning this issue to them).

[johannesodland]

I think this is the same issue I ran into in #9871. I'm closing that issue as a duplicate in favor of yours.

[graouts]

What I'm seeing in Chrome is that creating a scroll-driven animation puts it in the pending state originally. So, I think the play procedure is missing a step explaining that a pending play task is scheduled during step 10 when we abort.

[kevers-google]

I believe this section is missing a condition:

https://www.w3.org/TR/web-animations-1/#waiting-for-the-associated-effect

Presently the conditions for being ready are that:

• User agent has completed any setup...
• Timeline is active.

Adding a third condition that the animation has a start or hold time, resolves things. This keeps the animation in a play pending state until we have a resolved (auto-aligned) start time.

Previously, the timeline being active was sufficient, but now we potentially need a layout update to resolve the view timeline range and calculate an auto-aligned start time. This effectively leaves the animation not in effect while waiting on the animation to be ready, but this prevents a potential flicker by initializing with one start time only to jump to another after the view timeline range has been updated.

[graouts]

Note that Web Animations Level 2 already has an update for this section that matches what @kevers-google is saying:

the animation’s hold time or start time is resolved.

[kevers-google]

Ah yes. I see a TODO in the Blink implementation to add a condition to prevent aborting if playing a scroll driven animation. Apologies for not following up on that one.

In Blink, we have an extra condition to avoid an early abort if using a scroll timeline. This will require clarification in the spec. Hold time is expected to be set if using a document timeline, but not if using a scroll timeline. Looking at the play procedure in web-animations-2, I, I see an issue in the "if seek time is resolved" step. This has us setting the start time if using a finite-timeline, which worked prior to the introduction of view-timelines. As we don't necessarily know at the time of play what the start time should be for a scroll-timeline, we need to defer the calculation, and avoid an early abort if expecting a deferred start time. I'll follow up with Rob on this.

[graouts]

Ah yes. I see a TODO in the Blink implementation to add a condition to prevent aborting if playing a scroll driven animation. Apologies for not following up on that one.

I implemented the "auto-aligning the start time" procedure in WebKit in 285176@main and made a change to step 10 of the playing an animation procedure such as if the auto align start time flag is true and start time is unresolved we proceed with the rest of the procedure instead of bailing out.

See WebKit/WebKit@433599a#diff-ac012fc9792c68f4fdf706f4021da22aa0be5d72e7547cb42e3a9c3f36df6d18R1182.