Add 'prefers-reduced-motion' media feature #586

grorg · 2016-10-10T20:54:52Z

Added a new section for user preferences, with the assumption we'll get more of them.

Added the prefers-reduced-motion feature, discussed in #442

WebKit plans to implement this asap.

grorg · 2016-10-11T11:19:15Z

Oops. Hold off on this. I need to remove the None keyword.

Also clarify that 'default' can evaluate to false in a boolean context.

grorg · 2016-10-11T19:29:35Z

Ready now (fingers crossed)

grorg · 2016-11-10T19:30:41Z

@frivoal any comments on this?

frivoal · 2016-11-11T06:50:04Z

@grorg Sorry for the delay, I have not forgotten. This is in my todo list, gently making its way to the top. Hopefully it'll get there soon.

tabatkins · 2016-11-22T18:42:45Z

I don't particularly like using "default" as a falsey value. It doesn't feel falsey. On the other hand, I can see why "none" doesn't feel super appropriate here.

I'm okay with adding a new falsey value for the preference values, tho. What about "no" or "unknown"? Both of these feel much falsier than "default" to me, and also seem like they might be usable in the future for other MQs in a similar situation, where "0" or "none" don't quite mesh.

cookiecrook · 2016-11-30T08:49:53Z

unknown seems reasonable to me

inoas · 2016-11-30T14:17:25Z

The current wording - e.g. prefers-reduced-motion - does not allow any future granularity like say numbers, 3d vs 2d, or whatever comes to mind. It is very limiting in future.

Is there a particular reason these where not considered?

(motion-preference: all) / (motion-preference: reduced) / (motion-preference: disabled)
(prefers-motion: all) / (prefers-motion: reduced) / (prefers-motion: off)

Edit: @tabatkins the falsey-value issue is also being addressed in the alternative PR I hope.

Alternative to w3c#586 Having a good wording of the feature also gets around default value evaluating to true instead of false. Ref: w3c#586 (comment)

frivoal · 2016-12-06T06:54:36Z

I agree with the general shape of the proposal, the semantics and the new spec section, but I don't think the naming is great, and also dislike default being falsey.

My proposal back from #443 was
reduced-motion: none | prefer, which could possibly be expanded later with other truthy values, like for example force for when the UA is disabling all motions on its own, and we just want an MQ to let the author know about it so that they can react.

I don't think the force value is particularly likely on reduced-motion, but I do think it would be more likely on other similar "preference" properties, and I'd like to get the naming consistent.

I'd also be OK with a replacing none with another falsey value, but unknown feels wrong, because it feels like an invocation of the 3-valued logic described in https://drafts.csswg.org/mediaqueries-4/#evaluating.

cookiecrook · 2016-12-06T15:12:16Z

@inoas wrote:

The current wording - e.g. prefers-reduced-motion - does not allow any future granularity

Not true. Future values could be granular tokens, even a combined list, if someone wanted to implement them that way.

prefers-reduced-motion: reduce-parallax reduce-scaling; /* reduce-rotation, etc. */

the falsey-value issue is also being addressed in the alternative PR I hope.

Which alternative PR? Please link.

cookiecrook · 2016-12-06T15:18:30Z

@frivoal wrote:

My proposal back from #443 […snip…]

reduced-transparency: none | prefer | force
reduced-motion: none | prefer | force

I thought we settled that this syntax was unclear. reduced-motion: none; will leave many to believe it means "prefers no motion" rather than "no preference, so motion is okay."

inoas · 2016-12-06T15:45:39Z

@cookiecrook

The current wording - e.g. prefers-reduced-motion - does not allow any future granularity

Not true. Future values could be granular tokens, even a combined list, if someone wanted to implement them that way.

Sure it is true. The variable/setting itself declares that it is only about reduction not about disabling.

Because of the choice of words in this PR prefers-reduced-motion: disabled is ambiguous in the first place.

Which alternative PR? Please link.

If you look at my alternative PR #778 you can see the issue is not appearing anymore. That PR will btw also allow granularity not only in quantity but also quality (e.g. scaling vs parallax vs fading etc)

In my alt PR: motion-preference: none will simply say you have no preference, e.g. take the default.
motion-preference: disable will however be run for disabled motions, reduce will lower it...
And in future, IF DESIRED: values between 0 and 1000 would allow speeds, 0-100% would allow scaling, 0ms - 500ms would allow concrete max animation length.

cookiecrook · 2016-12-06T16:44:45Z

@inoas wrote:

The variable/setting itself declares that it is only about reduction not about disabling.

If you're talking about the term "reduced" in the property name, I think we're mincing semantics. Disabling motion is a reduction of motion, albeit a complete one.

Because of the choice of words in this PR prefers-reduced-motion: disabled is ambiguous in the first place.

This argument is a straw man fallacy because the PR does not include or suggest a disabled value. If needed at a later time, it could include an unambiguous prefers-reduced-motion: no-motion or even prefers-reduced-motion: motion-disabled.

Ref: w3c#778 Implements Issue: w3c#442 Alternative to w3c#586

Implements Issue: w3c#442 Alternative to w3c#586 Having a good wording of the feature also gets around default value evaluating to true instead of false. Ref: w3c#586 (comment)

nattarnoff · 2016-12-06T17:06:07Z

A complete reduction of non-interaction triggered animation has to be allowed in the settings. Given the scenario where items animate into a scene, users prone to motions sickness, vertigo, migraines, or distraction need this turned off yet usable.

Interaction triggered animation needs to be minimized, some stopped depending on what it is. Small animations such as color fades or animated icons on buttons or links likely won't cause a trigger point, but other animations non-essential to the control function may cause problems for users.

Reducing motion is good. But stopping/preventing/pausing animation and making the content still readable, actionable, and usable is needed. Additionally, best practices should be worded in a PE approach of no-motion, reduced-motion, full-motion structuring of CSS.

cookiecrook · 2016-12-06T17:34:37Z

@nattarnoff wrote:

A complete reduction of non-interaction triggered animation has to be allowed in the settings.

Currently, no platforms implement that in native UI or web UI. At such a time that any do, it would be appropriate to standardize in Web API.

Interaction triggered animation needs to be minimized, some stopped depending on what it is. Small animations such as color fades or animated icons on buttons or links likely won't cause a trigger point, but other animations non-essential to the control function may cause problems for users. Reducing motion is good. But stopping/preventing/pausing animation and making the content still readable, actionable, and usable is needed.

Herein lies the problem. As CSS and JavaScript-based animations are implemented as primitives, there is no good way for a browser to know which animations may be vestibular triggers. Stopping all motion entirely may be technically possible, but would be a heavy-handed approach that would likely result in a much worse user experience, because it would break the animations that convey meaning in the interface.

Apple has chosen to expose a user preference on its native platforms which allows authors to adopt and determine which animations are appropriate to reduce. This approach takes evangelism, but seems to be working well.

nattarnoff · 2016-12-06T17:53:53Z

Currently, no platforms implement that in native UI or web UI. At such a time that any do, it would be appropriate to standardize in Web API.

Why couldn't the Web API take the lead instead of waiting for native or web UI? If we establish the ability and best practice, are we not evangelizing that they should catch up and implement it?

there is no good way for a browser to know which animations may be triggers

Sadly after thinking through this a little more, I see this problem. Perhaps it is out of scope for this PR, but it is something that should be investigated. On the WCAG side of the fence, there is w3c/wcag21#18 which is about defining accessible animation from interaction. SC 2.2.2 Pause, Stop, Hide covers animation that isn't by direct user interaction.

cookiecrook · 2016-12-06T18:44:05Z

@nattarnoff wrote:

Why couldn't the Web API take the lead instead of waiting for native or web UI?

I think you'll find any proposal to disable all animations on the Web very controversial and difficult to implement well. Also, advocacy through specification is usually frowned upon.

Perhaps try an incubation approach in WICG or as a separate CSSWG issue instead? I agree that it's out-of-scope for this PR.

frivoal · 2016-12-07T02:50:16Z

This discussion is kind of spreading over a bunch of places. I made a comment in #442 (comment) to try and summaries all that's been said in terms of naming options, and try to find a winner.

cookiecrook · 2016-12-13T19:10:11Z

mediaqueries/Overview.bs

@@ -491,7 +491,7 @@ Evaluating Media Features in a Boolean Context</h4>
 	If the feature would be true for any value
 	<em>other than</em> the number ''0'',
 	a <<dimension>> with the value ''0'',
-	or the keyword ''none'',
+	or the keywords ''none'' and ''default'',


Please change default to no-preference per discussion

cookiecrook · 2016-12-13T19:10:34Z

mediaqueries/Overview.bs

+
+	<pre class='descdef mq'>
+	Name: prefers-reduced-motion
+	Value: default | reduce


cookiecrook · 2016-12-13T19:10:43Z

mediaqueries/Overview.bs

+	uses.
+
+	<dl dfn-type=value dfn-for="@media/prefers-reduced-motion">
+		<dt><dfn>default</dfn>


cookiecrook · 2016-12-13T19:12:00Z

mediaqueries/Overview.bs

+
+	</dl>
+
+


Maybe add a editorial note to the discussion in #442?

I'd rather not do that, at least not without a summary of what you want people to go look for in that giant rambling of ours.

grorg · 2017-01-11T18:59:51Z

Updated to use "no-preference" over "default".

frivoal · 2017-05-05T09:48:21Z

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

Add 'prefers-reduced-motion' media feature

92de527

Remove 'none' from prefers-reduced-motion.

c2aa564

Also clarify that 'default' can evaluate to false in a boolean context.

grorg assigned frivoal Oct 11, 2016

grorg added the mediaqueries-5 label Oct 11, 2016

grorg mentioned this pull request Nov 18, 2016

[mediaqueries] Reinstate "inverted-colors" somehow #732

Closed

inoas added a commit to inoas/csswg-drafts that referenced this pull request Nov 30, 2016

Add 'motion-preference' media feature

0990e78

Alternative to w3c#586 Having a good wording of the feature also gets around default value evaluating to true instead of false. Ref: w3c#586 (comment)

inoas mentioned this pull request Nov 30, 2016

Add 'motion-preference' media feature #778

Closed

cookiecrook mentioned this pull request Dec 6, 2016

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

Closed

inoas added a commit to inoas/csswg-drafts that referenced this pull request Dec 6, 2016

Add 'prefers-motion' media feature

93daa56

Ref: w3c#778 Implements Issue: w3c#442 Alternative to w3c#586

inoas added a commit to inoas/csswg-drafts that referenced this pull request Dec 6, 2016

Update

52a7f7e

Ref: w3c#778 Implements Issue: w3c#442 Alternative to w3c#586

inoas mentioned this pull request Dec 6, 2016

Add 'prefers-motion' media feature #793

Closed

cookiecrook reviewed Dec 13, 2016

View reviewed changes

Change 'default' to 'no-preference'

f9c94b4

frivoal closed this May 5, 2017

cookiecrook mentioned this pull request Oct 8, 2020

[scroll-animations] TAG feedback: interaction with prefers reduced motion #5321

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add 'prefers-reduced-motion' media feature #586

Add 'prefers-reduced-motion' media feature #586

grorg commented Oct 10, 2016

grorg commented Oct 11, 2016

grorg commented Oct 11, 2016

grorg commented Nov 10, 2016

frivoal commented Nov 11, 2016

tabatkins commented Nov 22, 2016

cookiecrook commented Nov 30, 2016

inoas commented Nov 30, 2016 •

edited

Loading

frivoal commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

inoas commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

nattarnoff commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 •

edited

Loading

nattarnoff commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 •

edited

Loading

frivoal commented Dec 7, 2016

cookiecrook Dec 13, 2016

cookiecrook Dec 13, 2016

cookiecrook Dec 13, 2016

cookiecrook Dec 13, 2016

frivoal Dec 14, 2016

grorg commented Jan 11, 2017

frivoal commented May 5, 2017

Add 'prefers-reduced-motion' media feature #586

Add 'prefers-reduced-motion' media feature #586

Conversation

grorg commented Oct 10, 2016

grorg commented Oct 11, 2016

grorg commented Oct 11, 2016

grorg commented Nov 10, 2016

frivoal commented Nov 11, 2016

tabatkins commented Nov 22, 2016

cookiecrook commented Nov 30, 2016

inoas commented Nov 30, 2016 • edited Loading

frivoal commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 • edited Loading

cookiecrook commented Dec 6, 2016 • edited Loading

inoas commented Dec 6, 2016 • edited Loading

cookiecrook commented Dec 6, 2016 • edited Loading

nattarnoff commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 • edited Loading

nattarnoff commented Dec 6, 2016

cookiecrook commented Dec 6, 2016 • edited Loading

frivoal commented Dec 7, 2016

cookiecrook Dec 13, 2016

Choose a reason for hiding this comment

cookiecrook Dec 13, 2016

Choose a reason for hiding this comment

cookiecrook Dec 13, 2016

Choose a reason for hiding this comment

cookiecrook Dec 13, 2016

Choose a reason for hiding this comment

frivoal Dec 14, 2016

Choose a reason for hiding this comment

grorg commented Jan 11, 2017

frivoal commented May 5, 2017

inoas commented Nov 30, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

inoas commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading

cookiecrook commented Dec 6, 2016 •

edited

Loading