[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.