Before this addition, you needed to extract the progress...

Before this addition, you needed to extract the progress from the animation’s effect. Like so:

```js
let progress = animation.effect.getComputedTiming().progress * 1;
if (animation.playState === "finished") progress = 1;
progress = Math.max(0.0, Math.min(1.0, progress)).toFixed(2);
```

Ugh.

Like 28 November at 14:26 | Open on front-end.social

4 comments

Bramus

Reading it from the effect was needed here because `animation.currentTime.value` gives you the progress of the _entire timeline_ and not just the _range_ you are targeting.

(Think of Scroll-Driven Animations that use `animation-range`)

With `Animation.overallProgress`, this is now a one-liner 😊

28 November at 14:26 | Open on front-end.social

Bramus

While already very handy, I don’t believe we are entirely there yet: `Animation.overallProgress` allows you to read the progress, but you still need a trigger for _when_ to read it.

This trigger depends on the type of timeline: for ScrollTimeline it is on scroll, and for DocumentTimeline you need a timer.

Seems a bit silly that you need different approaches based on what timeline you use (and also ironic that SDA needs a `scroll` listener). I want portable code.

28 November at 14:26 | Open on front-end.social

Bramus

To solve this, I believe that a `progress` event on Animation would be useful.

With such a `progress` event, the code to stay in sync with an animation’s progress would look like this, regardless of what type of timeline you use:

```js
anim.addEventListener('progress', () => { storeProgress(anim.overallProgress); });
```

This looks pretty sweet, right?

28 November at 14:27 | Open on front-end.social

Bramus

Anywho, back to `Animation.overallProgress`: you can try it out today in Chrome Canary with the Experimental Web Platform Features flag enabled.

It is expected to ship in Chrome 133.

28 November at 14:28 | Open on front-end.social