w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
319 stars 55 forks source link

Spec review for Scroll-driven Animations #828

Closed flackr closed 1 year ago

flackr commented 1 year ago

I'm requesting a TAG review of Scroll driven animation. This was previously reviewed as the scroll linked animations spec but has since undergone a quite substantial rewrite in response to https://github.com/w3c/csswg-drafts/issues/6674 with the goal of being easier to author reusable CSS scroll driven animations by using scoped named animations in a similar fashion to container names. The other major change is that element based animations are now driven using the ViewTimeline concept.

This specification defines mechanisms for driving the progress of an animation based on the scroll progress of a scroll container. These scroll-driven animations use a timeline based on scroll position, rather than one based on clock time. This module provides both an imperative API building on the Web Animations API and a declarative API building on CSS Animations.

Further details:

You should also know that...

In the previous TAG review a few issues were raised:

There were concerns about some of the use cases (which are admittedly already done today via script) being known triggers for vestibular disorders. We split this out into #5321 where we explored ideas and drafted a proposal #7440 for how we could work on addressing this concern more broadly for all animations. It's important to note that without declarative scroll driven animations, short of disabling Javascript the browser can't prevent these cases today - so the existence of this API puts us in a better position to address motion concerns in an automated way across more use cases.

There were also concerns with explicit element id references. In #6674 the spec underwent a significant rewrite such that animation references could be established via CSS using the DOM hierarchy in a way that is easily reusable across lists of elements.

At this point in time, we have worked through resolutions to the majority of the issues in the project tracker. While the spec edits have not completely caught up it is in line with the current thinking and broadly explains the feature.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

theres-waldo commented 1 year ago

cc @BorisChiou who has been working on this on the Mozilla side recently

LeaVerou commented 1 year ago

Hi there,

Thank you for taking our previous round of feedback into consideration and making appropriate changes. Also thanks for such a well written, exemplary explainer! We looked at this today during a breakout and we think it looks great. We're happy to see it move forward!