Intent to Implement: Scroll Timeline for Web Animations (JS only)

81 views
Skip to first unread message

Stephen Mcgruer

unread,
Dec 18, 2018, 9:03:02 AM12/18/18
to blin...@chromium.org, Robert Flack

Contact emails

smcg...@chromium.org, fla...@chromium.org


Design doc/Spec

Spec: https://wicg.github.io/scroll-animations

TAG Review: https://github.com/w3ctag/design-reviews/issues/330


Summary

Implement support for Scroll Timeline backed Web Animations. This will cover only the JavaScript portion of the Scroll Timeline spec, and will not support the CSS portion.


Previously we have implemented a large portion of the Scroll Timeline spec as part of the Animation Worklet Intent to Experiment (https://groups.google.com/a/chromium.org/d/msg/blink-dev/AZ-PYPMS7EA/DEqbe2u5BQAJ). Currently Scroll Timeline only supports Animation Worklet, but a lot of progress has been made on the spec and implementation recently and we are ready to start integrating it into the wider Web Animations functionality.


Note that the portion of Web Animations which has shipped (element.animate()) does not allow setting the timeline. Setting the timeline requires the (unshipped) Animation interface. The ScrollTimeline support for Web Animations will further be behind another flag (so that shipping Web Animations does not imply shipping ScrollTimeline).


Motivation

The ability to base an animation on a scroll position is required for effects such as Twitter's header bar, animating content as you scroll (popular with bootstrap-style websites), or animated parallax. An incomplete set of examples can be found at https://wicg.github.io/scroll-animations/#use-cases.


Currently web developers implement scroll-based animations either via scroll listeners or requestAnimationFrame reading the scroll position. These approaches are both main-thread heavy and may also fail in the presence of asynchronous scrolling. ScrollTimeline provides a way for the user agent to reduce the JavaScript performance overhead and potentially accelerate the effect on the compositor (which solves both the performance issue and the synchronization issue).


Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Public support (they are an editor on the spec, have recently engaged in positive conversations regarding moving it forward)

Safari: Public support (they are an editor on the spec, have recently engaged in positive conversations regarding moving it forward)

Web / Framework developers: Positive based on requests from AMP team and other web teams inside Google, expected positive in the general web too.


Ergonomics

The ergonomics risk should be low. ScrollTimelines should be at worst as expensive as the current approach web developers take for scroll-linked animations (and are often much better!).


Activation

I do not foresee activation risk. Developers can use this API by simply constructing a ScrollTimeline object and passing it into the appropriate Web Animations API instead of the (default) DocumentTimeline.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Is this feature fully tested by web-platform-tests?

Tests for ScrollTimeline in general already exist in WPT. Tests regarding how it interoperates with Web Animations will be added as the implementation moves forward.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6752840701706240


Requesting approval to ship?

No.


Reply all
Reply to author
Forward
0 new messages