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.