[mediaqueries] Media Feature: "reduce motion" user setting

[cookiecrook]

Tracking issue for Media Feature "prefers-reduced-motion"

Originally accepted at W3C TPAC, October 2014:
https://lists.w3.org/Archives/Public/www-style/2014Oct/0527.html

More recently discussed in February 2016 thread:
https://lists.w3.org/Archives/Public/www-style/2016Feb/0037.html

For spec:
https://drafts.csswg.org/mediaqueries/

[cookiecrook]

Allows certain views to remove or tone down animations. Platform preference is shipping on iOS, macOS, watchOS, and tvOS.

For example:

• launching an app on iOS changes to a subtle dissolve animation rather than a full-screen zoom.
• switching Spaces or launching Exposé on macOS Sierra

Customers regularly mention to us that common web site patterns (e.g. horizontal carousels or scroll-jacking animations) cause vestibular issues such as dizziness or vertigo. Web developers ought to be able to achieve a similar solution that app developers can achieve natively.

Some background:
http://simplyaccessible.com/article/balance-awareness/

Example calls for this support from the web development community:
https://twitter.com/zeldman/status/492805247455072256
https://twitter.com/webaxe/status/489159894860197888

Examples of vestibular trigger usage on sites:
Zoom while scrolling: http://www.nytimes.com/projects/2013/tomato-can-blues/
Spinning parallax starfield: http://cuberto.com

Update 2016-09-30: Desktop version only (simulated 3D zoom and spin triggers)
http://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=0

Site teams like @nytdesign could use this media feature via a standard CSS @ media block:

@media (prefers-reduced-motion) { /* reduce animation */ }

Or via JavaScript:

if (window.matchMedia('(prefers-reduced-motion)').matches) {
    /* reduce animation */
}

Update 2016-10-05: Another example:
http://qz.com/se/map-of-the-internet/

Update 2016-12-07: Video Podcast (~1 hour) by Microsoft Edge contributor detailing a variety of problematic web examples: "Infinite Canvas 6: Vestibular Disorders and Accessible Animation"
https://www.youtube.com/watch?v=QhnIZh0xwk0

[cookiecrook]

Changing these user settings don't change the rendering of anything. It just conveys a user preference that allows the frameworks, native apps, or web apps to adjust for this user preference/desire/need.

I should also note these proposed names don't fit well within the "none or truthy" pattern of some existing media features. It'd be awkward to specify that prefers-reduced-motion: none means "user is okay with animation." The none value here may be open to misinterpretation, so considering a default or no-preference value that behaves like none for boolean comparisons.

prefers-reduced-motion: [ default | reduce ];
prefers-reduced-motion: [ no-preference | reduce ];

[astearns]

If using 'none' is a pattern we want to maintain, then we could rename the prefers-* properties:

reduced-motion-preference: [ none | reduce ]
reduce-motion-preference: [ none | reduce ]

[cookiecrook]

The core reason this needs to expose a user preference rather than change something about the view is because UI varies greatly. There's no way a UA can reliably reduce or stop motion on behalf of the user and still guarantee an understandable interface. Exposing the pref gives authors a way to do this appropriately within the context of their own interfaces.

[cookiecrook]

Authors should ensure a reduction in motion does not negatively affect the usability of the interface. If movement was used to convey information (such as an action or relationship between two UI elements), the reduced motion variant should retain the same level of understandability.

For example, if a queuing action was conveyed by "moving the object into a queue position", then removing the animation entirely could result in the user not knowing the item had been successfully queued. It may be appropriate to draw the user's eye to the queued position using a different design metaphor, such as a badge or or variant of the fade technique.

[cookiecrook]

Vestibular triggers for animation include:

• any looping animation that cannot otherwise be stopped or autoplays on content load.
• any movement that is not triggered by the user (e.g. a notification bounces into view)
• any animations along a z-axis (e.g. zoom in or zoom out) or scaling of UI elements
• anytime two or more objects are simultaneously moving in different directions
• anytime two or more objects are moving at different speeds (parallax or momentum trailing effects)

[cookiecrook]

From @frivoal suggestion in #443, this could be

reduce-motion-preference: [ none | prefer | forced ]

• none: no preference
• prefer: web page author responsible for reducing animations or movement appropriately to avoid vestibular triggers or otherwise excessive motion.
• forced: motion (CSS animations, etc) prevented by the UA. Note: as far as I know, no platform or browser supports a setting like this, but I suppose it could happen.

PS. The none pattern still seems misleading in this context. It's silly that reduce-motion-preference: none means "user is okay with motion."

[tabatkins]

Drop the -preference. It's long and makes things harder to understand. (reduce-motion: none) says "don't reduce any motion". ^_^

Then (reduce-motion: prefer) works well too. (reduce-motion: forced) doesn't read quite as well, but I'm okay with it.

[inoas]

Why not keep adjectives:
(reduce-motion: none)
(reduce-motion: preferred)
(reduce-motion: forced) or(reduce-motion: requested) or (reduce-motion: required)

[inoas]

@cookiecrook reading that list makes me wonder if the property could become more fine grained in future (reduce-motion: loading-none fade-none zoom-none animation-none)

Another question would be if the users could in future have different levels of motion-animations (say 0-100%) and if the media query property should catch that?

[tabatkins]

"preferred" is above my comfortable "easy spelling" threshold; we try to keep CSS with as simple English as we can. (In general, past tense suffers from that, given the inconsistent end-consonant doubling.)

"required" doesn't quite communicate what's happening; it feels like a stronger version of "prefer", when actually it means something entirely different - it means that, in some way, the OS is turning off motion, and you better adapt to that lack.

[inoas]

What about:
(motion: all)
(motion: prefer-reduced) or (motion: reduced)
(motion: none) or (motion: disabled)

[smfr]

I prefer the names that make it clear that these media queries are about detecting user preferences, not about imperatives that affect animation behavior. "force" sounds too much like the latter.

[inoas]

@smfr thats the reason I suggested just motion above which can take "disabled" as a value.

[bradkemper]

I agree with @inoas that reduced should be in the value, not the property name. My suggestion is:
motion-pref: none
motion-pref: reduce
motion-pref: block or motion-pref: disable

[inoas]

Not a fan of the (short)cut (out of my mind I can't site a single css property that is a short-cut; also non-english speakers my not instantly know what it means).

[inoas]

Also motion-pref: none is ambiguous. Does it mean you have no preference or does it mean you that your preference is set to "no motion"?

So I suggest

(motion: all)
(motion: reduced) or (motion: prefer-reduced)
(motion: none)

or

(motion-preference: all)
(motion-preference: reduced)
(motion-preference: disabled)

[cookiecrook]

@inoas wrote:

(motion: none)

none is reserved for non-truthy matching (e.g. no match for (motion)) meaning the default value, so this won't work. How about this instead:

(prefers-reduced-motion: default) /* 'default' should be a non-truthy boolean match like 'none' */
(prefers-reduced-motion: reduce)

So that that authors could use the valueless shorthand:

@media (prefers-reduced-motion) { /* disable excess motion */ }`

[cookiecrook]

And future preference-based media features could use the prefix pattern "prefers-" to distinguish the difference between these types:

• user wants the author to account for this preference (e.g. prefers-reduced-motion)
• system has changed display, so author may account for this change (e.g. monochrome)

[cookiecrook]

Regarding @frivoal's proposal for a forced value, I think it's highly unlikely any UA would ever disable all motion, as it's ambiguous to determine which transitions or animations would be vestibular triggers. Even if it's possible to disable all motion at the platform level, doing so would be likely to break the user experience more than it helps.

[inoas]

If none is reserved what about motion: off, edit, e.g.:

(motion: all)
(motion: reduced) or (motion: prefer-reduced)
(motion: off) or (motion: disabled)

or

(motion-preference: all)
(motion-preference: reduced)
(motion-preference: disabled)

or

(prefers-motion: all)
(prefers-motion: reduced)
(prefers-motion: off)

@cookiecrook Not a fan of the shorthand, but the idea with the prefers- prefix seems to be a good one!

[grorg]

Prototype implementation in WebKit https://trac.webkit.org/r207173

[Mr0grog]

Even though WebKit has started to implement, I’d also love to see this framed in the positive if possible. My experience that been that double negatives (e.g. prefers-reduced-motion: none) tend to trip people up much more often, especially if they are non-native English speakers.

While that necessarily makes the valueless shorthand less useful, I think the increased clarity is worthwhile.

I like the idea of a prefers-* convention for these, too, so I’d suggest something similar to @inoas:

(prefers-motion: yes) or (prefers-motion: all) or (prefers-motion: default)
(prefers-motion: reduced)

(Side note: thanks @cookiecrook and @grorg for pushing this forward; I’m really looking forward to having access to this, regardless of the naming it winds up with in the end :)

[cookiecrook]

@Mr0grog Last suggestion breaks the Boolean context. For example, this would mean the opposite of what it appears to mean.

@media (prefers-motion) { /* does not prefer motion */ }
@media not (prefers-motion) { /* does want motion */ }

[cookiecrook]

Not certain I understand the double negative concern.

You wrote:
(E.g. prefers-reduced-motion: none)

…but that is not being proposed. The current implementation and spec value is 'default' (not 'none') which was intended to remove the negative ambiguity in all the other suggestions.

[cookiecrook]

@inoas wrote:

… what would you do about these:

increased-contrast-preference: decrease; /* say night mode */
reduced-motion-preference: double; /* say motions are okay but I want them to be very fast */

1. You suggested: increased-contrast-preference: decrease; /* night mode */ Given the broad range of contrast settings across implementations, I doubt we'll ever be able to standardize a single generic "increase contrast" setting. If anything, it's likely to be several more granular such as prefers-reduced-transparency, prefers-minimum-contrast-ratio, etc. It also seems likely that a "night-mode" media feature could be separate.

2. You suggested: reduced-motion-preference: double; /* motion okay but I want them very fast */ This again seems unlikely to me, but if needed, seems better as a timing preference specific to transitions, rather than all motion. Maybe prefers-minimum-transitions: no-preference | immediate | fast? (Note: Not an endorsement.)

Edit: prefers-minimum-contrast-ratio isn't a great name but hopefully the point was clear: indication of a specific and measurable preference rather than a generally ambiguous "I want higher contrast."

Edit: removed "straw man" comment that was overly dismissive. My apologies to @inoas.

[inoas]

That's very concrete. The examples I brought up where not endorsements either. They should just reflect the issue of having the scale/value-implication in the MQ feature name/variable.

A) It is not about straw men here, but where the whole set of user-preferences MQ features is heading towards. The current design seems to just concern the current issue at hand. I have not seen an answer to this yet:

E.g. wouldn't that lead to the requirement to introduce a new MQ feature, vs just a new value, every time the value implications set by the MQ feature name make strong assumptions about the variable scale (non, ordinal, interval, ratio), default value and boolean association - that do not match a possible value (see above)?

B) From the other side of the argument: What is the really big benefit of having a default value that evaluates to boolean context?

To say it in other words: Are you certain that having the scale/value-implication within the mq-feature name (which could potentially create a mess of mq-features, because feature names similar to "prefers-reduced-motion" transport too much information about the value sets as pointed out and explained above) is worth having a boolean default context?

If you are certain then prefers-reduced-motion: no-preference | reduce should work, despite that it is already painful in my mind to write prefers-reduced-motion: disabled.

[cookiecrook]

@frivoal Devil's advocate example in favor of @inoas's -preference suffix: preferences where a non-default numeric value does not imply a specific direction:

minimum-font-size-preference: no-preference | <font-size>

[frivoal]

@inoas
I think there is no advantage to having
motion-preference: no-preference | reduced | increased
instead of
prefers-reduced-motion: no-preference | reduced
prefers-increased-motion: no-preference | increased

In usage, you need to write either:
@ media (motion-preference: reduced) {}
or
@ media (prefers-reduced-motion) {}
and the following is useless:
@ media (motion-preference) {}

prefers-reduced-motion: no-pref | reduce is extensible, but only towards things that go in the same direction. e.g:
prefers-reduced-motion: no-pref | reduce | reduce-motion-sickness | reduce-vibrations | reduce-rotations
You can be specific as to the kind of motion you want to reduce, but you can also use it as a blunt tool, in a boolean context without specifying which kind of motion you care to reduce, and its still works.

Or, turning the argument around: because authors will use things in a boolean context if we make it possible, we should either not make it possible, or make sure that any value added later is compatible the original semantics. I think you're arguing for the former. I think it is possible, but does not bring any improvement over doing it as separate queries, and takes away the possibility of having multiple refinements expressed via boolean semantics.

[inoas]

@frivoal It is not about the usage, sure having a boolean context is nice to have, but does not having it block anything?

prefers-reduced-motion: no-pref | reduce is extensible, but only towards things that go in the same direction. e.g:

Exactly, that is already the problem. For this MQ feature and for any MQ features to come that don't want to follow this path or cannot (say minimum-font-size-preference).

You already pointed out yourself that you would need prefers-increased-motion - but sometimes things don't go into directions.

Or, turning the argument around: because authors will use things in a boolean context if we make it possible, we should either not make it possible, or make sure that any value added later is compatible the original semantics.

What is the big benefit of using the boolean context?

I think you're arguing for the former. I think it is possible, but does not bring any improvement over doing it as separate queries

I don't have a problem with multiple/separate queries.

Do you see any problems having having scale/direction/value implications within the MQ feature name (a variable name!), in so far that it requires to create very similar MQ feature names in future just to be able to also set other values?

All those MQ features then first have to be supported and it takes probably a lot longer than just new values?

I don't see the benefit of having a blunt tool-option (boolean context), yet?!

, and takes away the possibility of having multiple refinements expressed via boolean semantics.

@frivoal Can you show an example on where @media (motion-preference) would take away the possibility of having multiple refinements?

Anyway, if can confirm that you are certain that trading off the requirement of implicit default scales/values/directions (possibly also for future user preference MQs) vs just a valid boolean-context, is worth it, then my argument closes here.

[frivoal]

All those MQ features then first have to be supported and it takes probably a lot longer than just new values?

I don't think new value vs new MQ would make any difference to how long it takes to get it implemented.

I don't see the benefit of having a boolean context

• If it stays a yes/no switch (which is decently likely), that's the idiomatic thing
• If we add values that are variants of yes, it gives authors the choice of distinguishing between the nuances, or if they prefer putting all of the in the same bucket.
• If authors don't particularly care about which type of yes they're reacting to, they should use the boolean context syntax, and their code will automatically apply if/when we add different kinds of yes later.
• If we add unrelated values we can do so in separate properties, which is no worse than adding separate values in a non-boolean property.

Can you show an example on where @media (motion-preference) would take away the possibility of having multiple refinements?

Calling the MQ motion-preference doesn't prevent you from adding any number of refinment values to it, but it does get in the way of using it without a value (i.e. in a boolean context) like @media (motion-preference) because it doesn't tell you anything actionable: there's a preference, but a preference for what: more motion, less motion, different motion? You can't know, so either you don't use it, or you assume one kind and force the hand of future spec additions despite a property name that didn't suggest that particular meaning.

[grorg]

https://trac.webkit.org/r209842

prefers-reduced-motion: reduce | no-preference

Note that it is "no-preference" not "no-pref"

[inoas]

no-preference still a lot better than ambiguous none 👍 thanks @cookiecrook !

[frivoal]

Available here: https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion

[bradkemper]

After reading all these, I want to suggest this:

[bradkemper]

Motion-reduction: none | preferred | all

[bradkemper]

I don't mind the "preferred" being past tense. It just feels more natural that way. It is easy to type because it is easy to remember and say in that form. p.s. Sorry, the github client I am using can't type carriage returns without submitting.

[frivoal]

@bradkemper With what semantics? what does the all value mean?

As we've already argued back and forth on this a lot, I am not all that excited about reopening the naming side of this discussion. Especially now that apple has shipped it. Doesn't mean we cannot consider it, but you're going to have to be pretty convincing :)

[bradkemper]

Yeah, I arrived at this a little too late, it seems. Oh, well, I can deal with it, if that's the case. I'm just throwing it out there because it is what seems most natural and simple to me, and I think should be easy to remember and understand.

My values would mean this:

Motion-reduction: none = Normal, no preference indicated one way or the other, or user chose to not have motion reduced. The default.

Motion-reduction: preferred = User expressed a preference for reduced motion. Author should oblige.

Motion-reduction: all = user expressed a preference to let the UA decide how to reduce motion (blocking all animation and transitions involving position, margin, etc., for instance). Author writes rules to deal with this more severe situation.

[inoas]

@bradkemper well we went through most of that...

1. motion-reduction: none is ambiguous without knowing what the specs author's intention was. motion-reduction: no-preference would work there.

2. Motion-reduction: preferred was deemed to by too hard to type here [mediaqueries] Media Feature: "reduce motion" user setting #442 (comment)

3. Motion-reduction: all There was no dominant voices wanting the MQ feature to be able to detect a user preference that communicates disabled motions. I really wanted this in. However then the whole MQ feature name makes no sense as long as it implies reduce or reduction. TBH it seemed to me that both, the Google/Android and the Apple/iOS teams, did not want to be able to specify zero-animations (for whatever product/design/marketing reasons). Bad for the user (choice, epilepsy, speediness, battery) though.

Anyway, not being able to detect either disabled motion or the preference for no motion (which are two different things) is really bad about this MQ spec.

@frivoal well the bad choices aside (sorry) the best to work with now is the MQ feature name as it exists and then adding new or more fine grained values.

prefers-reduced-motion could have prefer-disabled and hardware-disabled where first would mean the user made that preference/choice and 2nd would mean either the firmware/hardware is not capable or the user disabled animations deliberately.

However this could also flow into a separate MQ feature if that makes more sense, like say platform-motions or similar.

[frivoal]

Right. While I don't think the naming we landed is perfect, the proposals made here have already been litigated, and don't really bring anything new to the debate.

If you insist, we could bring this to the group for further discussion, but I'd rather leave it at rest.