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

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

From: inoas via GitHub <sysbot+gh@w3.org>
Date: Tue, 13 Dec 2016 14:10:25 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-266747599-1481638222-sysbot+gh@w3.org>
@frivoal It is not about the usage, sure having a boolean context is 
nice to have, but does *not having* it block anything?

> `prefers-reduced-motion: no-pref | reduce` is extensible, but only 
towards things that go in the same direction. e.g:

Exactly, that is already the problem. For this MQ feature and for any 
MQ features to come that don't want to follow this path or cannot.

You already pointed out yourself that you would need 
`prefers-increased-motion` - but sometimes things don't go into 

> Or, turning the argument around: because authors will use things in 
a boolean context if we make it possible, we should either not make it
 possible, or make sure that any value added later is compatible the 
original semantics.

What is the big benefit of using the boolean context?

> I think you're arguing for the former. I think it is possible, but 
does not bring any improvement over doing it as separate queries

I don't have a problem with multiple/separate queries.

Do you see any problems having having scale/direction/value 
implications within the mq feature name (variable name), in so far 
that it requires to create very similar MQ feature names in future 
just to be able to also set other values? All those MQ features then 
first have to be supported and it takes probably a lot longer than 
just new values?

I don't see the benefit of having a `blunt tool`-option (boolean 
context), yet?!

> , and takes away the possibility of having multiple refinements 
expressed via boolean semantics.

@frivoal Can you show an example on where `@media (motion-preference)`
 would take away the possibility of having multiple refinements?

Anyway, if **can confirm that you are certain** that trading off the 
requirement of implicit default scales/values/directions _(possibly 
also for future user preference MQs)_ vs just a valid boolean-context,
 is worth it, then my argument closes here.

GitHub Notification of comment by inoas
Please view or discuss this issue at 
using your GitHub account
Received on Tuesday, 13 December 2016 14:10:41 UTC

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