[csswg-drafts] [web-animations-2] [scroll-animations-1] Auto-aligning the start time of an animation associated with a scroll timeline (#10965)

graouts has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations-2] [scroll-animations-1] Auto-aligning the start time of an animation associated with a scroll timeline ==
I'm working on implementing [Scroll-driven Animations](https://drafts.csswg.org/scroll-animations-1/) 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](https://drafts.csswg.org/web-animations-2/#auto-aligning-start-time). Per [HTML Processing Model: Event loop](https://drafts.csswg.org/scroll-animations-1/#event-loop):

> When updating timeline current time, the [start time](https://drafts.csswg.org/web-animations-1/#animation-start-time) of any attached animation is conditionally updated. For each attached animation, run the procedure for [calculating an auto-aligned start time](https://drafts.csswg.org/web-animations-2/#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](https://drafts.csswg.org/web-animations-1/#animation-play-state) is idle, abort this procedure.

The [play state is idle](https://drafts.csswg.org/web-animations-1/#play-states) when:

> All of the following conditions are true:
> 
> - The [current time](https://drafts.csswg.org/web-animations-1/#animation-current-time) of animation is [unresolved](https://drafts.csswg.org/web-animations-1/#unresolved), and
> - the [start time](https://drafts.csswg.org/web-animations-1/#animation-start-time) of animation is [unresolved](https://drafts.csswg.org/web-animations-1/#unresolved), and
> - animation does not have either a [pending play task](https://drafts.csswg.org/web-animations-1/#pending-play-task) or a [pending pause task](https://drafts.csswg.org/web-animations-1/#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](https://drafts.csswg.org/web-animations-2/#playing-an-animation-section) after step 10:

> If the following three conditions are all satisfied:
> 
> - animation’s [hold time](https://drafts.csswg.org/web-animations-1/#animation-hold-time) is [unresolved](https://drafts.csswg.org/web-animations-1/#unresolved), and
> - aborted pause is false, and
> - animation does not have a [pending playback rate](https://drafts.csswg.org/web-animations-1/#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](https://drafts.csswg.org/web-animations-1/#the-current-time-of-an-animation):

> If any of the following are true:
> 
> - the animation has no associated [timeline](https://drafts.csswg.org/web-animations-1/#timeline), or
> - the associated [timeline](https://drafts.csswg.org/web-animations-1/#timeline) is [inactive](https://drafts.csswg.org/web-animations-1/#inactive-timeline), or
> - the animation’s [start time](https://drafts.csswg.org/web-animations-1/#animation-start-time) is [unresolved](https://drafts.csswg.org/web-animations-1/#unresolved),
>
> The [current time](https://drafts.csswg.org/web-animations-1/#animation-current-time) is an [unresolved](https://drafts.csswg.org/web-animations-1/#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?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10965 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 27 September 2024 14:35:09 UTC