Re: [w3ctag/design-reviews] WG New Spec: Scroll-Triggered Animations (Issue #1167)

DavMila left a comment (w3ctag/design-reviews#1167)

> Hi [@DavMila](https://github.com/DavMila), just wondering if you had any thoughts in response to our comment above?

Hi @matatk, we discussed this shortly after your comment but I apologize for taking so long in getting back to this.

> * The robustness of this pattern on sites in general - e.g. when afforded by scripting - can be poor. For example: triggers firing the wrong number of times; things going wrong if the user scrolls back. Have you considered how these issues may be resolved through standardization?

One of the choices we made was to leverage [scroll timelines](https://developer.mozilla.org/en-US/docs/Web/API/ScrollTimeline) which were introduced along with [scroll-driven animations](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Scroll-driven_animations). Timelines, via the [ranges](https://drafts.csswg.org/scroll-animations/#view-timelines-ranges) API, offer developers a robust way of referring to portions of a scroll container. To use the “user scrolls back” case mentioned as an example, timeline triggers are designed to allow authors specify two ranges - this means that for a given side of the scroll port, authors can separate the boundary at which scrolling forward fires the animation from the boundary at which scrolling backwards does. One of the use cases we prioritized simplifying was being able to specify the ranges as `contain / cover` which provides a separation of the trigger points so that on one end of the scroll port triggering only happens when the element comes fully into view or goes fully out of view.
We believe that this boundary separation, together with semantically connected “entry” and “exit” concepts (i.e. entry and exit must alternate) are likely to foster the development of UIs that are predictable and user-friendly.

> * Historically, all page content was loaded in and was available to ATs - it might just be off screen, but could be explored. If content is loaded dynamically in response to scrolling, this could exclude some users. (It doesn't seem like that's _inherent_ here, but it seems like a pattern that may more prominently emerge following this.)

I think our expectation is that use of this feature will apply to elements coming in and out of the viewport/scrollport, which are typically elements that are already loaded into the DOM.

> * Scrolling and animation can cause huge cognitive issues (e.g. distracting, disorienting). We have `prefers-reduced-motion` but we're not sure how much consideration has been given to providing guidance for authors on how to ensure an equitable UX - especially in cases of complex animations revealing - or even themselves acting as - content.

We recognize that this is an important issue to consider and we think that this is something that developers should be considering in the context of animations in general. To this end, we noticed that the [css-animation spec](https://drafts.csswg.org/css-animations-2/) doesn’t have an accessibility section similar to the [css-transitions spec](https://www.w3.org/TR/css-transitions-1/#accessibility). So, we are [working on](https://github.com/w3c/csswg-drafts/pull/13243) adding an accessibility section with a strong recommendation on prefers-reduced-motion. I think that one potential advantage of declarative scroll-triggered animations is the ability for the user agent to make modifications to the animations on a page according to the user’s needs. It might be more difficult for a user agent to do this with scripted scroll-triggered animations.

> * Does this interact with/affect the focus in any way?
> 

No, it doesn’t directly affect focus. In theory, it would be possible for an author to set up an animation that affects other CSS properties that, in turn, interact with focus , e.g. display. However, that’s true of animations today.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1167#issuecomment-3855068508
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1167/3855068508@github.com>