We discussed this on today's APA WG call and the consensus is: yes, please! We do think that view transitions should be disable-able. We mused on whether prefers-reduced-motion may be a good signal for the user's desire on this - however, this case is one of the (several, perhaps) cases where some users would likely need the feature to be completely disabled.

Does this invite the notion of a prefers-no-motion query? Not sure. There are several motion/animation sources over which it'd be good to give users control that aren't affected by media queries, so there seems to be a gap/opportunity of some kind here (but this feels like it's going way bigger than scope, so I'll desist).

There are two components of view transitions: running the callback, and running the animations. The callback that is run is part of the page state that modifies DOM in some way to advance the state. That isn't an enhancement and must be run (assuming script can indeed run startViewTransitions). It's a common pattern to have

if (document.startViewTransition) {
  document.startViewTransition(updateCallback);
} else {
  updateCallback();
}

As for the animations, view transition constructs CSS animations and relies on that to execute the visual transition. I presume that the treatment for view transitions would not be any different from the treatment of CSS animations.

+1 to the comment above. Since the animations in VT are powered by CSS/web animations (from UA and/or author), the strategy we use for CSS animations/web animations overall should by design apply to VT as well.

Reading through the comment threads on #7440 though, there is a desire to permit cross-fade style of animations wherever possible. If the user has a "no-motion/forced-reduced-motion" type of setting, then VT is maybe in a unique position to do this easily? The default UA CSS (which adds a name to the root with a cross-fade of old/new state) is already a simple cross-fade between the 2 states. We could force all VTs to only apply UA CSS rules for VT props/pseudos for the "no-motion/forced-reduced-motion" mode. @fantasai @flackr fyi.

there is a desire to permit cross-fade style of animations wherever possible. If the user has a "no-motion/forced-reduced-motion" type of setting, then VT is maybe in a unique position to do this easily?

As someone who is impacted by motion animations but not cross-fade animations, this would work for me on initial site visit. I do find even cross-fade animations distracting and also get impatient if they happen too often, for example on every page of a website or every time I click something.

We mused on whether prefers-reduced-motion may be a good signal for the user's desire on this - however, this case is one of the (several, perhaps) cases where some users would likely need the feature to be completely disabled.

Does this invite the notion of a prefers-no-motion query?

The term "prefers-reduced-motion" is an artifact of Apple getting there first and choosing the setting label "Reduce Motion" in macOS and iOS. Windows 11 calls it "Animation effects" with a setting of On or Off. Android calls it "Remove animations".

All of the above are exposed to browsers, and browsers expose them to websites via the identical prefers-reduced-motion media query.

In order to have separate prefers-reduced-motion and prefers-no-motion queries, OS developers would have to provide two controls and browser developers would have to expose those controls to websites.

iOS additionally has a control to prefer cross-fades on menus. I don't know whether iOS makes it available to apps. I also don't know whether any browser reads that setting and exposes it to websites if iOS does make it available.

If prefers-reduced-motion as it currently exists is set, the safest practice would be to assume there is no safe animation, since we don't know why the site visitor has set Reduce Motion on/Animations effects off/Remove animations on. Even necessary animation might be best initiated through a play button. For example, one can set Firefox to not play gif animations; if one then wants to play the animation, one right-clicks the image and chooses Play or Loop.

In order to have separate prefers-reduced-motion and prefers-no-motion queries, OS developers would have to provide two controls and browser developers would have to expose those controls to websites.

This could always be browser setting, doesn't have to come from the OS?

I don't like the idea of complete animation suppression for view transitions only. It should be done at a lower layer, for CSS transitions, CSS animations and web animations. So it applies to all animations and not just the ones associated with a view transition.

I would be open to changing the UA CSS to only do a cross-fade if @prefers-reduced-motion is set. So the default browser provided animations do the right thing if the author is not overriding them. We have to consider the compat risk though. @nt1m @emilio, thoughts?

I don't like the idea of complete animation suppression for view transitions only. It should be done at a lower layer, for CSS transitions, CSS animations and web animations. So it applies to all animations and not just the ones associated with a view transition.

Yeah, that has been thought about. Some users do set transition-duration: 0 !important in user stylesheets in order to prevent transitions, same with animation: none !important or so.

Firefox disables <marquee> animations when prefers-reduced-motion matches, fwiw, so there is some precedent. In general I think there's some tension here: Sometimes prefers-reduced-motion is just that, a preference, but sometimes it is an accessibility need...

Seems fine to change the UA CSS so that default transitions do the right thing, but yeah I agree we should generally try to come up with a reasonable stance on prefers-reduced-motion, and make it affect all CSS transitions / animations equally. I think @flackr had talked about something like that not that long ago?

The CSS Working Group just discussed [css-view-transitions] Users need to be able to disable view transitions https://github.com/w3c/csswg-drafts/issues/10267, and agreed to the following:

• RESOLVED: in cases of prefers-reduced-motion the UA stylesheet will define a cross-fade animation by default, without size/position animation

RESOLVED: in cases of prefers-reduced-motion the UA stylesheet will define a cross-fade animation by default, without size/position animation

Is there currently a way to test user preference media features like PRM in WPT? If not, the view-transition-related Interop Focus Area proposals could be updated to include this expectation.

An issue came up when spec-ing the resolution. We wanted to set this up such that the keyframes stay the same with or without prefers-reduced-motion but the animation property doesn't use the keyframe. This would allow the author to trivially add the animation back if needed.

But the keyframes being used to animate the group include other properties like backdrop-filter so removing it completely won't be right. The backdrop-filter will also not animate and I'm not sure if it counts as "motion", it feels like cross-fading. We could change the keyframe itself as in this PR: #10996 but this increases the compat risk associated with this change. So wanted to run it past the group to confirm. @nt1m @mattwoodrow @emilio.

We should also discuss this in the context of layered capture since that will add a bunch of other properties and we'll have to decide which ones make sense to interpolate in prefers-reduced-motion mode. @noamr