- From: inoas via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Dec 2016 20:14:41 +0000
- To: public-css-archive@w3.org
That's very concrete. The examples I brought up where not endorsements either. They should just reflect the issue of having the scale/value-implication in the MQ feature name/variable. A) It is not about straw men here, but where the whole set of user-preferences MQ features is heading towards. The current design seems to just concern the current issue at hand. I have not seen an answer to this yet: > E.g. wouldn't that lead to the requirement to introduce a new MQ feature, vs just a new value, every time the value implications set by the MQ feature name make strong assumptions about the variable scale (non, ordinal, interval, ratio), default value and boolean association - that do not match a possible value (see above)? B) From the other side of the argument: What is the really big benefit of having a default value that evaluates to boolean context? To say it in other words: Are you certain that having the scale/value-implication within the mq-feature name _(which could potentially create a mess of mq-features, because feature names similar to "prefers-reduced-motion" transport too much information about the value sets as pointed out and explained above)_ is worth having a boolean default context? If **you are certain** then `prefers-reduced-motion: no-preference | reduce` should work, despite that it is already painful in my mind to write `prefers-reduced-motion: disabled`. -- GitHub Notification of comment by inoas Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/442#issuecomment-266539802 using your GitHub account
Received on Monday, 12 December 2016 20:14:47 UTC