- From: inoas via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Dec 2016 14:10:25 +0000
- To: public-css-archive@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 directions. > 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 https://github.com/w3c/csswg-drafts/issues/442#issuecomment-266747599 using your GitHub account
Received on Tuesday, 13 December 2016 14:10:41 UTC