- From: inoas via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Dec 2016 23:14:17 +0000
- To: public-css-archive@w3.org
> I'm feeling more and more strongly that standard media features should convey "UI matches this state. Author MAY adapt." (monochrome, etc.) and the preference media features should convey "User wants author to match this preference. Author SHOULD adapt." (prefers-reduced-motion or motion-pref[erence], etc.) If this above is not standardized, and the group of stand-alone user-preference MQs starting with (reduced)-motion gets in, that sounds good 👍 , so that *that* discourse doesn't from zero next time. my POV: - If the MQ feature is (also) about capability detection, it should not have a negative connotation in its feature name, else you would make assumptions about what default hardware is - and that's a really temporary point of view. - If the MQ feature is **just** about preference detection, it _could_ have a negative connotation in its feature name (and by doing so allow a default false value). - If you want preference **and** capability detection be side by side (where it makes sense) in future, it would be helpful for users, if they were worded similarly. E.g. `motion-preference` + `motion` would make sense. - `prefers-reduced-?????` would also imply that there is always at least an ordinal scale for any future preference features and their values, say about ink, color, contrast, transparency, etc. to have a consistent naming. If you prefer not to see green+red on the same page, that's hardly qualifying under ordinal scales ;). In consequence we will have tons of different MQ names for capabilities and/or preferences, some having reduce in it word, others increase, maybe swap, or whatever *transformation* you can think of. - the pref abbreviations okay IMHO, not sure if it could be mixed up with prefix/preface (though it made little sense) http://www.dictionary.com/browse/pref- - I don't think saving the 6 letters is worth it (CSS consistency). * * * ``` motion-preference: no-preference | reduce /* or reduce-all */ ``` ... looks good to me 👍. It is clear, allows to add `disabled` if there is the will/desire, allows future granularity and doesn't imply that it is only about reduction (it could, say, have the value `double` for speedier motions). The only question I have: Not sure how if the split between preference and capability is a good one **or** a bad one. Maybe @frivoal or @Mr0grog want to elaborate. -- GitHub Notification of comment by inoas Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/442#issuecomment-266149002 using your GitHub account
Received on Friday, 9 December 2016 23:14:24 UTC