MQ5 User Prefs: prefers-reduced-transparency #1709
Conversation
|
Aside that … the MQ feature name never (as in not here nor with prefers-reduced-motion) should have included the direction of the scale and an implication that you cannot request prefers-disabled-transparency etc. … this is great and will mean authors can help those visually impaired. |
|
@inoas wrote:
We talked about this in the other thread. It could always be expanded at a later date with values that still make sense: For example… prefers-reduced-transparency: [ none | reduce | force | opaque | bikeshed]
👍 |
mediaqueries-5/Overview.bs
Outdated
| @@ -478,6 +478,36 @@ Detecting the desire for less motion on the page: the 'prefers-reduced-motion' f | |||
|
|
|||
| </dl> | |||
|
|
|||
| <h3 id="prefers-reduced-transparency"> | |||
| Detecting the desire to reduce the use of transparent or translucent layering effects on the page: the 'prefers-reduced-transparency' feature</h3> | |||
There was a problem hiding this comment.
Could you shorten this title a bit? This a bit unwieldy, and does not need to reproduce the whole content of the section. How about:
Detecting the desire for reduced transparency on the page: the 'prefers-reduced-transparency' feature
There was a problem hiding this comment.
Transparency is a boolean concept; translucency and opacity are not. If the feature name contains transparency for the sake of easy vs more correct language, then the docs can easily contain translucent and/or opacity if authors are search the docs for those (more correct) terms.
But - as long as @cookiecrook hadn't had more specifics in mind - skipping the layering effects vs just page 👍
Detecting the desire for reduced transparency or translucency on the page: the 'prefers-reduced-transparency' feature
There was a problem hiding this comment.
Transparency is a boolean concept; translucency and opacity are not.
I'm affraid I'll disagree on this one. I check the dictionary, and it gave not hit of this nuance. https://encrypted.google.com/search?q=partially+transparent&tbm=isch gives plenty of relevant results. Apple used this phrasing in their System Preferences to express the same concept. Using the word transparency is fine.
There was a problem hiding this comment.
Okay, but clearly many UI effects nowadays combine a certain levels of opacity/transparency with certain levels of translucency (see example graphics on https://en.wikipedia.org/wiki/Transparency_and_translucency) and as long as this MQ should detect a combined preference then transparency for the name and translucency as part of the docs seems reasonable. My guess is still that apple picked "transparency" as that is an easy concept to get to every user.
opacity is btw the key word in CSS used to describe (non boolean shades of) transparency of layers, not transparency.
There was a problem hiding this comment.
Agree that the standard English usage of all of these related terms are all roughly equivalent, and all encompass degrees.
For example, I was taught that opaque/translucent/transparent refer to the degree of opacity: something is translucent when light passes thru, but it's not clear enough to actually see details on the far side; something is transparent when you can actually see thru it to at least some degree. (The boundary is obviously very fuzzy, no pun intended, but the categories are clear enough, no pun intended. "Privacy glass" is more on the translucent side, cloudy plastic is translucent, etc. Normal windows are transparent. Rice paper is translucent.)
In other words, the definitions are definitely intertwined and uncertain enough that we can really use any of them here; there's no way to defend any particular definition as Definitely Correct.
|
@grorg You may be interested in this thing I just merged here. If something's wrong, please open a new issue, thx. |
|
Thanks @frivoal |
Discussed at recent F2F meeting, and in CSS Issue #443