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

@cookiecrook 

> I'm not convinced we should use the same media feature to mix 
exposed-preference values with what you're calling forced values. The 
forced values are just standard media features that allow the author 
to account for what has already changed.

Right, that's definitely a possibility. The reason I think they are 
useful to join in a single query is that you may often want to react 
in the same way. Once you have designed a variant of your page that 
does not use animations yet works well (or without transparency, or 
using less ink) to cater to users that have expressed that preference,
 it makes perfect sense to also use that variant when the browser 
would forcibly try to apply the same effect, to avoid the side effects
 of a probably more blunt way of during things off and to provide the 
desired alternative. So you'd use the query in a boolean context, 
without much concern for whether you were merely requested to turn 
transparency off, or if you wouldn't get transparency anyway:
`@media (reduce-transparency) { /* good opaque variant of your 
design*/ }`

At the same time, from this list of things we've considered so far, 
the only that has a "prefers" mode in one OS and a "forced" mode in 
another is invert-colors, and that's the one that is least suited to 
applying the same styles in both case. ink-saving is "forced" on all 
OSes/UAs, while motion and transparency are "prefers" when they exist.
 I think there were a few other MQs that were discussed along the way,
 but IIRC they were theoretical. So maybe I'm wrong.

> Col 6: The media feature name needs to clearly convey that, unlike 
most media features, it's the type that requires author adoption. So 
far, only the prefers-* and the *-preference suggestions do so.

This one largely contradictory to goes against my Col 1. I'm still on 
the fence, as I think there is some merit to the idea of prefers | 
forced, but I am less sure than I used to, so maybe you're right.

> Col 7: Values must be expandable. The prefers and forced values 
would suffice for very few user preferences, so values could be 
whatever type is appropriate for the media feature. As a few trivially
 contrived examples: `temperature-unit-preference: no-preference | 
fahrenheit | celsius` or `font-weight-preference: no-preference | 
bold`

I think this actually overlapps quite a bit with my Col.2. Col 2 sorts
 of boils down to:
* there should be a single falsy value that express a lack of 
preference either way
* and a set of truthy values that express various requests to the 
author to change things away from the norm
* and a property name that makes sense when the thing is evaluated in 
a boolean context.

You don't really need the boolean context / falsy / truthy aspect for 
your Col 7 criteria, but if we set things up that way, it will work 
for your purpose as well. Especially if we have a naming that makes 
your Col 6 happy.

> With this added criteria, these seem like better solutions.
> motion-preference: no-preference | reduce; /* possible expansion: 
reduce-rotation, etc. */
> prefers-reduced-motion: no-preference | reduce;
I don't like the first one, because it works poorly in a boolean 
context `@media (motion-preference) {}` does not give you a good sense
 of what it is supposed to mean.

The second one is  verbose and uses repeats the prop name in the 
value, but if we accept your Col 6 over my Col 1, it gets the 
semantics right.

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

Received on Wednesday, 7 December 2016 16:55:23 UTC