Hi there @majido,

Thanks for raising this issue, and my apologies that it took us so long to respond. We are working through some process improvements on that front.

In terms of this proposal, I am curious whether there has been thought given to the interaction between this (and by extension all Houdini features which concern animation) and the prefers-reduced-motion media query.

What effect would using a prefers-reduced-motion media query have if authors have used an AnimationWorklet to create a custom animation? Would the animation not run by default? Or would the author need to take some specific action via the matchMedia() function?

Might it make sense to make prefers-reduced-motion a first-class API in this context, so that authors might be encouraged provide an alternate version of animations (for example, regular scrolling tends to be acceptable) which may be less problematic for anyone who has the prefers-reduced-motion preference set?

Thanks for the comment @alice.

What effect would using a prefers-reduced-motion media query have if authors have used an AnimationWorklet to create a custom animation? Would the animation not run by default? Or would the author need to take some specific action via the matchMedia() function?

I believe prefers-reduced-motion in the context of Animation Worklet should behave similar to how it behaves with Web Animations specially given that currently the only channel to use Animation Worklet is through Web Animations API i.e., by creating an animation. So with that in mind, the preference should not turn off the animation by default (since animation may not produce any motion) and it would be up to authors to take the preference into account.

My understanding is that currently the best practice is to have authors use matchMedia to decide when to create an animation or not. For example:

const hasNoMotionPreference = 
           window.matchMedia('(prefers-reduced-motion: no-preference)').matches
if (hasNoMotionPreference) {
  animation = new Animation(keyframesWithMotion).play();
  workletAnimation = new WorkletAnimation('my_animator', keyframesWithMotion).play();
} else {
  animation = new Animation(keyframesWithoutMotion).play();
  workletAnimation = new Animation('my_animator', keyframesWithoutMotion).play();
}

This should work the same work for WebAnimations and Animation Worklet.

In cases where the author needs to have their customization behave differently to reduce motion we have a reasonable generic solution that allows the worklet animation to pass additional options to its animator. See the example below:

const  prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches
const workletAnimation = new WorkletAnimation(
    'fancy_motion_animator', 
    keyframes, 
    { prefersReducedMotion }
).play()

registerAnimator('fancy_motion_animator', class {
   constructor(options)  {
     this.options = options;
  }
  
  animate(currentTime, effect) {
     if (this.options.prefersReducedMotion) {
        //  reduced motion version, maybe directly go to last frame instead of animating!
        effect.localTime = effect.getTimings().duration;
     } else {
        // regular version.
        effect.localTime = currentTime;
     }
  }
});

Might it make sense to make prefers-reduced-motion a first-class API in this context, so that authors might be encouraged provide an alternate version of animations (for example, regular scrolling tends to be acceptable) which may be less problematic for anyone who has the prefers-reduced-motion preference set?

I am not so sure about this. As I mentioned Animation Worklet already provides a generic method that allows authors to send motion preference and customize their animator logic if it is indeed a motion producing animation. I prefer this generic solution over a something custom tailored to this particular preference.

However I think it is a great idea to highlight reduced motion preference in the specification and explainer examples and show how it can be used. I filed css-houdini#903 to address this.

Thanks for the considered response! The code examples are really well thought through to demonstrate different strategies for handling prefers-reduced-motion options.

Regarding matchMedia() and the possibility of having a first-class API to detect a prefers-reduced-motion state, I don't know that having an existing generic API is necessarily a sufficient argument against having a dedicated API, particularly when media queries are designed primarily to be used from CSS code, not JavaScript.

Indeed, much of what can be done with Web Animations can be done with CSS, as I understand it - in theory you could probably construct an animation in JS by building CSS strings and setting appropriate attributes, but that is inconvenient and error-prone.

Your two code examples interestingly use opposite strategies (as I'm sure you're aware): one detects a lack of user preference, while the other detects a reduce preference. This seems like a good example of the extra cognitive load involved in using matchMedia() - you need to be able to construct the media query and understand the result. A first class API would remove that cognitive load.

I wouldn't consider this a blocking issue for AnimationWorklet, especially since Web Animations does share the same issue (as you allude to), but it would be nice to consider a first-class API (or small set of APIs) for detecting prefers-reduced-motion: reduce which may be used in either context. I believe this would encourage authors to consider this case more often.

For example, one starting point might be to consider the two strategies in your code examples:

• allow setting a secondary effect on an Animation to be used if a user prefers reduced motion
• allow an author to opt in to using a single static keyframe if a user prefers reduced motion.

Hi, @Alice and I are taking another look at this during our Tokyo F2F.

We note an implementability concern raised elsewhere, namely, in browser engine architectures which have a process boundary between scrolling and JS execution, "scroll-linked effects with worklets would not be possible[...] to implement" (without rearchitecting). I wondered if this feedback had resulted in spec changes, but it doesn't look like there's been much work on the spec since June or thereabouts. What are your current thoughts on this?

We note that there were some security issues flagged in the Intent to Ship thread, and some spec changes were alluded to.

Since, other than Tess' concerns about implementability/compatibility, we don't have any other substantive feedback to offer here (though it would be good if the relevant groups at least considered reifying prefers-reduced-motion as I suggested earlier), we're going to close this for now - please open a new issue linking to this one if there are significant spec changes you'd like us to take a second look at.