[css-view-transitions] Users need to be able to disable view transitions

[plinss]

This is based on feedback from a related TAG review.

View transitions also need to be considered in #5321 and #7440.

There seems to be an attitude that view transitions are primary content under the complete control of the page author. This violates the priority of constituencies and potentially creates inaccessible content for many users.

It needs to be made clearer that view transitions are an enhancement and the web page should not break if they are disabled (and given the script component, it may be necessary to define behavior when they are disabled). The user also needs a mechanism to disable them.

[matatk]

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).

[vmpstr]

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.

[khushalsagar]

+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 https://github.com/w3c/csswg-drafts/issues/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.

[CharlesBelov]

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.

[khushalsagar]

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?

[emilio]

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?

[css-meeting-bot]

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

The full IRC log of that discussion

<matatk> subtopic: [css-view-transitions] Users need to be able to disable view transitions https://github.com/w3c/csswg-drafts/issues/10267
<astearns> github: https://github.com/w3c/csswg-drafts/issues/10267
<fantasai> matatk: We discussed in APA, idea of being able to do some kind of reduction on View Transitions we thought would be helpful
<fantasai> ... but also acknowledge that there is a subtle, but big, difference between reducing and disabling motion
<fantasai> ... wrt motion, there is good infrastruction for reducing but not disabling
<fantasai> ... so consistency issues
<fantasai> ... We're generally in favor of some sort of control, but wondering what is the latest from CSSWG
<khush> q+
<fantasai> vmpstr: We can respect prefers-reduced-motion and set up different default animation that doesn't have motion and does a cross-fade
<fantasai> ... but if authors customize, then that's a regular CSS animation -- they are responsible at that point
<PaulG> q+
<matatk> q+ to ask about 'one-sided' transitions
<matatk> q?
<matatk> ack khush
<fantasai> khush: There's another issue where flackr had a proposal for a forced no-motion mode
<PaulG> q-
<fantasai> ... that would disable all CSS animations completely
<fantasai> ... that seems better path for a CSS-wide fix for it
<fantasai> ... didn't want to do something specific for View Transitions
<fantasai> khush: one detail is that we do something generic for animating position and size
<matatk> q?
<fantasai> ... can adjust the defaults for that accordingly
<matatk> ack me
<Zakim> matatk, you wanted to ask about 'one-sided' transitions
<fantasai> matatk: if moving between documents and ...
<fantasai> vmpstr: Animation runs on one page only. The outgoing page doesn't control the animation in any shape or form
<fantasai> ... just specifies which parts will participate
<matatk> q?
<fantasai> ... incoming page controls the animation, so that's where prefers-reduced-motion would take effect
<fantasai> ...
<fantasai> matatk: OK, we'll take as homework on what to recommend
<fantasai> vmpstr: We can resolve now I guess
<fantasai> ... in cases of prefers-reduced-motion we will construct a cross-fade animation by default, without size/position animation
<fantasai> vmpstr: Thoughts? Objections?
<kbabbitt> q+
<fantasai> chrishtr: removing animation completely would be a separate feature
<matatk> ack kbabbitt
<fantasai> kbabbitt: Do we need to be concerned about whether this is detected as a user preference through timing or something?
<fantasai> fantasai: it's a media query
<fantasai> khush: by design, want authors to adapt to it
<fantasai> kbabbitt: but do we want the info to be detectable (concern wrt fingerprinting)
<fantasai> gregwhitworth: If mapping to prefers-reduced-motion, you can already get that info via JS
<fantasai> matatk: if document doesn't give an alternative, then you'd use the default cross-fade?
<fantasai> ... another option would be to not run the normal one, but that's not reducing it
<fantasai> ... I think that would surprise authors
<fantasai> khush: Firefox disables marquee animations in this mode already, so there's some precedent
<fantasai> chrishtr: UA stylesheet would normally do cross-fade + transform
<fantasai> ... with the second rule for prefers-reduced-motion would only do cross-fade
<fantasai> ... author's rules would always override
<matatk> ack fantasai
<TabAtkins> fantasai: Whatever we put in the default UA stylesheet
<TabAtkins> fantasai: Unless we specifically make it an override, it'll get overridden by the author
<matatk> q?
<TabAtkins> fantasai: so if they create a custom animation, it'll work in both modes. They'll have to create their own reduced one.
<TabAtkins> fantasai: This'll just change the default animation
<fantasai> matatk: So up to us to say if we think this is a good idea
<PaulG> +1 for the default
<fantasai> matatk: Motion doesn't come just from CSS
<fantasai> ... if the user says prefers-reduced-motion, is there any browser engine looking into reducing other forms of motion?
<fantasai> fantasai: prefers-reduced-motion is a MQ that the author has to adjust for; UA can oly adjust it's defaults
<fantasai> ... if adding a forced mode, we would take more heavy-handed approach to suppressing author-provided motion
<fantasai> s/provided/specified/
<fantasai> matatk: [missed]
<fantasai> flackr: smooth scrolling can get turned off, small example
<fantasai> emilio: we do that too
<fantasai> emilio: it's interesting to have different heuristics here, but similar to forced colors
<matatk> q?
<khush> q+
<fantasai> ... if was ? then we could take more aggressive measures
<fantasai> ... but right now no standard way to expose
<fantasai> ... so would need different settings or different browsers
<fantasai> ... may or may not be solveable
<fantasai> ... ideally we do something like that, where we have a forced-reduced-motion mode
<fantasai> ... but I don't think we're there yet
<zcorpan> q?
<matatk> ack khush
<fantasai> khush: Not all browsers have setting, try to infer from OS settings
<miriam> s/was ?/it was a need (not just a preference)/
<fantasai> ... e.g. Android no animations gets mapped to prefers-reduced-motion
<fantasai> ... so what was in the OS vs what's in the browser don't match very well
<astearns> proposed resolution: in cases of prefers-reduced-motion the UA stylesheet wil define a cross-fade animation by default, without size/position animation
<astearns> RESOLVED: in cases of prefers-reduced-motion the UA stylesheet will define a cross-fade animation by default, without size/position animation
<vmpstr> \o/

[cookiecrook]

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.

[khushalsagar]

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: https://github.com/w3c/csswg-drafts/pull/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