- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Dec 2016 02:16:57 +0000
- To: public-css-archive@w3.org
> All those MQ features then first have to be supported and it takes probably a lot longer than just new values? I don't think new value vs new MQ would make any difference to how long it takes to get it implemented. > I don't see the benefit of having a boolean context - If it stays a yes/no switch (which is decently likely), that's the idiomatic thing - If we add values that are variants of yes, it gives authors the choice of distinguishing between the nuances, or if they prefer putting all of the in the same bucket. - If authors don't particularly care about which type of yes they're reacting to, they should use the boolean context syntax, and their code will automatically apply if/when we add different kinds of yes later. - If we add unrelated values we can do so in separate properties, which is no worse than adding separate values in a non-boolean property. > Can you show an example on where `@media (motion-preference)` would take away the possibility of having multiple refinements? Calling the MQ `motion-preference` doesn't prevent you from adding any number of refinment values to it, but it does get in the way of using it without a value (i.e. in a boolean context) like `@media (motion-preference)` because it doesn't tell you anything actionable: there's a preference, but a preference for what: more motion, less motion, different motion? You can't know, so either you don't use it, or you assume one kind and force the hand of future spec additions despite a property name that didn't suggest that particular meaning. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/442#issuecomment-266923299 using your GitHub account
Received on Wednesday, 14 December 2016 02:17:03 UTC