Re: [csswg-drafts] [mediaqueries] Media Feature: "reduce motion" user setting

> @inoas suggested these as potential default values:
I came up with these suggestions but I discarded them in this PR 
https://github.com/w3c/csswg-drafts/pull/778

The idea there is: `motion-preference: default | reduce | disable`
As for the prefix, this could also work: `prefers-motion: default | 
reduced | disabled`

I do believe that it is good to detect a user preference to reflect 
the desire to have no motions at all. Thus I do believe the disable/d 
value in a media query is a good thing. However it could easily work 
without.

`prefers-reduced-motion` however has the issue that the 
**media-feature** itself already carries a value, aka `reduced`. I 
don't see the reason to do so and it leads to many issues around 
"negative" value of the feature not being clear if they reset the 
filter to default or whatever they do:

```
prefers-reduced-motion: none; // does the user not prefer motion? Does
 the user not prefer reduced motion?
prefers-reduced-motion: auto; // does the user prefer reduced motion 
or not?
prefers-reduced-motion: disabled; // does the user prefer reduced 
motion or not?
```
The feature *name* itself just makes it hard to make sense out of it 
once it gets into dichotomy states, e.g. "user wants default 
animations, user wants maximum animations, user wants minimum 
animations, user wants no animations". 

So instead of having: `prefers-FEATURE: default` we have to have 
`prefers-reduced-motion: unknown`. If the UA/App does not map through 
a feature preference - or if it is not set - it is safe to assume to 
use defaults anyway. However `prefers-reduced-motion: default` is not 
clear again. Does the user prefer reduced animations? Or does he not 
and wants to take defaults?


-- 
GitHub Notification of comment by inoas
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/442#issuecomment-265203544 
using your GitHub account

Received on Tuesday, 6 December 2016 16:50:26 UTC