- From: inoas via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jul 2017 10:51:44 +0000
- To: public-css-archive@w3.org
@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 https://github.com/w3c/csswg-drafts/issues/442#issuecomment-248352927 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. -- GitHub Notification of comment by inoas Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/442#issuecomment-317701751 using your GitHub account
Received on Tuesday, 25 July 2017 10:51:46 UTC