Intent to Ship: Scroll-driven animations
Robert Flack
Contact emails
fla...@chromium.org, kev...@chromium.org, gir...@chromium.org, and...@chromium.org
Explainer
https://github.com/w3c/csswg-drafts/blob/main/scroll-animations-1/EXPLAINER.md
Specification
https://drafts.csswg.org/scroll-animations-1
Summary
ScrollTimeline and ViewTimeline are an extension to the Web Animations spec which allow developers to use the position of a scroller or the position of an element within a scroller as an input 'time' rather than the default monotonic clock time. This enables fast scroll-based animations, such as a shrinking navigation bar, without requiring user script execution. They can be declared and instantiated both via CSS and Javascript used in CSS animations and Web Animations.
Blink component
Blink>Animation
Search tags
animation, scroll, scrolling
TAG review
https://github.com/w3ctag/design-reviews/issues/828
The concerns raised in the initial review have been addressed with resolutions called out in the subsequent review.
TAG review status
Pending
Link to origin trial feedback summary
https://docs.google.com/document/d/1OLouOhe122Fb9hPkArpbe3I7fcOglmrKcI4yRVPQ1D4/edit
Risks
Interoperability and Compatibility
# animation-duration
A notable change was made to the animation-duration property. In particular the animation-duration now supports 'auto' values and the initial value of animation-duration is changed to 'auto'[1] which aligns a CSS animation's default duration with one constructed via the web animations API[2], and allows the default duration to be automatically computed for scroll driven animations as well as the upcoming group and sequence effects.
Visually this is identical for existing animations because an "auto" duration on a plain document timeline results in an intrinsic iteration duration[3] of 0. However, the "auto" value will now be visible in the developer observed style so code which may have parsed the time value expecting a 0 could now break. E.g. parseFloat(getComputedStyle(elem).animationDuration) results in NaN for "auto" duration compared to 0.
On Canary the computed duration for 0-duration animations is accessed on 0.05% of page loads. As a baseline, computed webkit-font-smoothing property (i.e. a property often not intentionally accessed) is accessed on 0.02% of page loads for the same set.
[1] https://drafts.csswg.org/css-animations-2/#animation-duration
[2] https://drafts.csswg.org/web-animations-1/#the-effecttiming-dictionaries
[3] https://drafts.csswg.org/web-animations-2/#intrinsic-iteration-duration
Gecko: In development (https://github.com/mozilla/standards-positions/issues/347)
WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2020-June/031228.html) Updated request posted at https://github.com/WebKit/standards-positions/issues/152
Web developers: Positive
Other signals:
# animation-duration A notable change was made to the animation-duration property. In particular the animation-duration now supports 'auto' values and the initial value of animation-duration is changed to 'auto'[1] which aligns a CSS animation's default duration with one constructed via the web animations API[2], and allows the default duration to be automatically computed for scroll driven animations as well as the upcoming group and sequence effects. Visually this is identical for existing animations because an "auto" duration on a plain document timeline results in an intrinsic iteration duration[3] of 0. However, the "auto" value will now be visible in the developer observed style so code which may have parsed the time value expecting a 0 could now break. E.g. parseFloat(getComputedStyle(elem).animationDuration) results in NaN for "auto" duration compared to 0. On Canary the computed duration for 0-duration animations is accessed on 0.05% of page loads. As a baseline, computed webkit-font-smoothing property (i.e. a property often not intentionally accessed) is accessed on 0.02% of page loads for the same set. [1] https://drafts.csswg.org/css-animations-2/#animation-duration [2] https://drafts.csswg.org/web-animations-1/#the-effecttiming-dictionaries [3] https://drafts.csswg.org/web-animations-2/#intrinsic-iteration-duration
Gecko: In development (https://github.com/mozilla/standards-positions/issues/347)
WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2020-June/031228.html) Updated request posted at https://github.com/WebKit/standards-positions/issues/152
Web developers: Positive
Other signals:
Activation
Scroll driven animations can be built as a progressive enhancement to an otherwise static scrolling page. It is also possible to polyfill the API - see https://github.com/flackr/scroll-timeline/ for a wpt-tested polyfill that is slightly out of date.
Scroll driven animations can be built as a progressive enhancement to an otherwise static scrolling page. It is also possible to polyfill the API - see https://github.com/flackr/scroll-timeline/ for a wpt-tested polyfill that is slightly out of date.
Security
No known risks.
No known risks.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
The current tooling provided by DevTools supports showing/editing of the used keyframes and the newly introduced CSS properties. There is active work being done to improve dedicated tooling over time.
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?
Yes
Flag name
ScrollTimeline
Requires code in //chrome?
False
Tracking bug
http://crbug.com/1023424
Sample links
https://scroll-driven-animations.style
Estimated milestones
| Shipping on desktop | 115 |
| Shipping on Android | 115 |
| Shipping on WebView | 115 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
There a few issues still being resolved:- https://github.com/w3c/csswg-drafts/issues/8694 Awaiting consensus on specific timing and conditions regarding when we repeat style/layout to avoid animation flicker. - https://github.com/w3c/csswg-drafts/issues/7759 We agree on roughly how deferred timelines should work, just need resolution on the specific syntax. Minor API Tweaks: - https://github.com/w3c/csswg-drafts/issues/8656 Support explicit auto duration in shorthand - https://github.com/w3c/csswg-drafts/issues/8746 Requiring <dashed-ident> timeline names
We expect to resolve these before the branch to ensure they don't represent a source of compat risk. The remaining scroll-animations issues are expected not to change the existing syntax / behavior and will be considered as extensions for the API in the future.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6752840701706240
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/8V4ixKVmNY4/m/vJQdo9GCBgAJ Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/AZ-PYPMS7EA/m/DEqbe2u5BQAJ
This intent message was generated by Chrome Platform Status.
Alex Russell
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TOwKQLH_By5y5GQGiHPmkfnu2COC_geD1JA8E13kj8N7A%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQjZaQf9iLaqY-T-riD9QbOXHrTT2MG0aGOB%3DQk9MBMVDw%40mail.gmail.com.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUS%3DeWpx4wmiv%3DE%2Bu-6y1pjSAk-yYxtf9B6TxDPDGLCqQ%40mail.gmail.com.