W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2016

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

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Dec 2016 02:47:59 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-265340257-1481078878-sysbot+gh@w3.org>
Naming is hard. Here's an attempt at justifying my own 
biases^H^H^H^H^H^H^H^H^H^H finding semi-objective criteria to evaluate
 these names.

1. This is probably one of a set of similar preference properties, and
 we should pick a naming scheme that works for all of them. A 
forced-off value is fairly unlikely for animations, but I do think it 
is likely for other similar properties (invert colors, save-ink), so 
the naming scheme should work for it.
2. This should be usable in a boolean context, and, the name of the 
property should make sense when used without an explicit value.
  2.1. The value for "prefers to [reduce motion | invert colors | no 
transparency | save some ink | reduce contrast]" and for "forces all 
[motion off | colors to be inverted | transparency off | ink saving 
measures on | contrast enhancement on]" should probably have the same 
truth value. It's also possible that we'll later add some "prefers 
some subset of [motions | transparency...] off", and that should also 
have the same truth value.
  2.2. On the other hand, I think the "nothing special, proceed as 
usual" value is likely to be alone, so it makes sense for it to be the
 single falsy value, and for the other values to be the truthy ones, 
matching other MQs which only ever have a single falsy value.
  2.3 Moreover, it makes sense for the falsy value to be the one that 
corresponds to "nothing special, proceed as usual" for another reason:
 people normally design their pages with animations, and would use 
this MQ to detect a situation where the opposite should happen, and 
being able to use it as `@media (mq-name)` is nicer than `@media not 
3. the falsy value in media queries is usually called `none` or `0`. 
Reusing that would be good. If that's not practical, making up a new 
one is better than using confusing naming. But the new one is only to 
make things clearer, so it should not itself be misleading. For 
instance, `unknown` suggests we'd be using the 3-value logic with 
true/false/unknown states described in 
https://drafts.csswg.org/mediaqueries/#evaluating, and `default` 
doesn't sound falsy.
4. short names are better than long ones
5. repeating the same word in the property name and in the value(s) 
isn't great

So, with that in mind, let me try to rate the values proposals that 
have been put forward. Ratings are :white_check_mark: for good, 
:no_entry_sign: for bad, :warning: for OK but not great. The keyboard 
marked with * is the falsy one, if any. Within this table, I think the
 first 3 columns are important, and the last 2 are nice to have, but 
not deal breakers.

| | 1.  potential "forced off" value works | 2. omitting value makes 
sense | 3. non misleading falsy value name (important), preferably 
reusing `none` (nice to have) | 4. short names | 5. no repetition | 
`motion-preference:  no-preference* | reduce` |⚠️|🚫|✅|⚠️| 🚫
`prefers-reduced-motion:  default* | reduce `|⚠️|✅|⚠️|🚫|🚫
`prefers-reduced-motion:  no-preference* | reduce `|⚠️|✅|✅|🚫|🚫
`reduced-motion-preference: none* | reduce `|⚠️|✅|⚠️|🚫|🚫
`reduce-motion-preference:  none* | reduce `|⚠️|✅|⚠️|🚫|🚫
`reduce-motion-preference: none* | prefer | forced `|⚠️|✅|⚠️|🚫|🚫
`reduce-motion: none* | prefer | forced`|✅|✅|🚫|✅|✅
`reduce-motion: default* | prefer | forced`|✅|✅|⚠️|✅|✅
`reduce-motion: unknown* | prefer | forced`|✅|✅|⚠️|✅|✅
`reduce-motion: no* | prefer | forced`|✅|✅|✅|✅|✅
`reduce-motion: no-preference* | prefer | forced`|✅|✅|✅|⚠️|✅
`motion: none* | all | prefer-reduced`|✅|🚫|✅|✅|✅
`motion: none* |all | reduced`|✅|🚫|✅|✅|✅
`motion: all | prefer-reduced* | disabled*`|✅|⚠️|⚠️|✅|✅
`motion: all | reduced* | disabled*`|✅|⚠️|⚠️|✅|✅
`motion: all | prefer-reduced | disabled`|✅|🚫|🚫|✅|✅
`motion: all | reduced | disabled`|✅|🚫|🚫|✅|✅
`motion-preference: all | reduced |  disabled`|⚠️|🚫|🚫|✅|✅
`motion-preference: default | reduce | disable`|⚠️|🚫|🚫|✅|✅
`prefers-motion: all | reduced* | off*`|⚠️|⚠️|⚠️|✅|✅
`prefers-motion: default | reduced* | off*`|⚠️|⚠️|⚠️|✅|✅

Now, my eyes are bleeding and none of these words look like real words
 anymore. But overall, I feel like
- if the word reduced (or something close) isn't in the name, either 
the boolean semantics get inverted, or disapear entirely, and both are
- If the word preference (or something close) is in the name, adding a
 forced value becomes weird. While this would be tolerable for this 
property alone, it sucks for the other ones in the same series.
- for all other names that have been proposed, `none` is a counter 
intuitive name of the falsy value.

So my preference goes to something like:
`reduce-motion: no* | prefer | force` or
`reduce-motion: no-preference* | prefer | force` or
`reduced-motion: no* | prefer | forced`

The rest of the series would look something like that:
`invert colors: no | prefer | forced`
`save-ink: no | prefer | forced`
`reduce-transparency: no | prefer | forced`

GitHub Notification of comment by frivoal
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 7 December 2016 02:48:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:26 UTC