Re: [csswg-drafts] [mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS (#2943)

The CSS Working Group just discussed `prefers-contrast / high`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: prefers-contrast / high<br>
&lt;fantasai> github:<br>
&lt;fantasai> Summary of current state is at y'all<br>
&lt;fantasai> florian: whole issue is very long, so added a comment yesterday summarizing the stat eof discussion<br>
&lt;fantasai> florian: We have a prefers-contrast media query<br>
&lt;fantasai> florian: as specced today, prefers-contrast: no-preference | low | high | forced<br>
&lt;fantasai> florian: We also have a forced-colors MQ<br>
&lt;fantasai> florian: in order to make it possible to do a very common thing, we have included forced keyword into prefers-contrast as well<br>
&lt;fantasai> florian: regardless of whether contrast preference for low or high or something else, generally desired to reduce visual complexity<br>
&lt;fantasai> florian: so having low/high/forced on the same media feature makes possible to do @media (prefers-contrast)<br>
&lt;fantasai> florian: that's why forced is in there<br>
&lt;fantasai> florian: but this issue isnot about forced, it's about the rest of the media features<br>
&lt;fantasai> florian: we have low and high<br>
&lt;fantasai> florian: and high is the tricky bit<br>
&lt;fantasai> florian: MacOS has "increased contrast" which doesn't do white vs black etc.<br>
&lt;fantasai> florian: it increase contrast, but not extremely so<br>
&lt;fantasai> florian: people from Apple believe 'high' describes extreme contrast, and want a different keyword for that<br>
&lt;fantasai> Rossen_: What is increasing contrast?<br>
&lt;fantasai> florian: It's a content-aware thing that will use more contrasty colors and adds borders<br>
&lt;fantasai> florian: but doesn't do such extreme transformation of colors as forced-colors mode<br>
&lt;fantasai> florian: screenshot at<br>
&lt;fantasai> florian: with that said, current spec actually does not limit 'high' to extreme version<br>
&lt;fantasai> florian: the way it is described would include the way Apple / Gmail do high contrast mode<br>
&lt;fantasai> florian: But maybe we need to distinguish between higher and extreme contrast<br>
&lt;fantasai> florian: Note that we are not discussing forced mode<br>
&lt;fantasai> florian: but a non-forced preference for higher contrast<br>
&lt;fantasai> florian: and distinguishing between "somewhat high" and "extremely high" contrast preferences<br>
&lt;fantasai> florian: One way minimalistic way to make it more palatable to Apple is to rename 'high' to<br>
&lt;fantasai> 'increase'<br>
&lt;hober> q+<br>
&lt;fantasai> florian: So maybe matching the name a bit better would help make clear that spec categorizes both as the same keyword<br>
&lt;fantasai> florian: but maybe there's a need to distinguish between the two<br>
&lt;fantasai> florian: However<br>
&lt;fantasai> florian: In many cases you don't want to distinguish<br>
&lt;fantasai> florian: author wants to create one mode for higher-contrast preferences<br>
&lt;fantasai> florian: not two<br>
&lt;fantasai> florian: and writing (prefers-contrast: high) and (prefers-contrast: increase) is unweildy<br>
&lt;fantasai> [which, incidentally, makes it less likely that the author will get it right -- fantasai]<br>
&lt;astearns> ack hober<br>
&lt;gregwhitworth> q+<br>
&lt;fantasai> myles: We'd like for james craig to be present for discussion, and he's on vacation this week<br>
&lt;fantasai> astearns: Would it be OK to discuss a bit and not resolve?<br>
&lt;fantasai> astearns: OK, we'll defer resolving, but let's see how far we get<br>
&lt;astearns> ack gregwhitworth<br>
&lt;fantasai> gregwhitworth: I actually just turned this on to play with it<br>
&lt;fantasai> gregwhitworth: terminology aside, the end goal is still trying to achieve the same thing<br>
&lt;fantasai> gregwhitworth: they obviously don't go to the same extreme lengths as high-contrast<br>
&lt;fantasai> gregwhitworth: but to the author of a website, the goal for the end-user is the same<br>
&lt;fantasai> gregwhitworth: I want to see more of the content, I want it to stand out<br>
&lt;fantasai> gregwhitworth: Although e.g. Yahoo doesn't override due to that, if I was an author, it would show me user wants increased or high contrast<br>
&lt;fantasai> gregwhitworth: I don't think it's a different setting, just different approach<br>
&lt;fantasai> gregwhitworth: you're trying to segment content to improve legibility<br>
&lt;florian> q?<br>
&lt;fantasai> florian: I agree with gregwhitworth<br>
&lt;fantasai> florian: I'm not convinced that we should have a way to distinguish<br>
&lt;fantasai> florian: and even if we do, we don't require authors to always distinguish<br>
&lt;fantasai> florian: One way to solve this is to keep the spec as-is, as per gregwhitworth's argument, they are different implementations of the same goal<br>
&lt;fantasai> florian: An alternative, calling 3[B], is to have two levels of high contrast<br>
&lt;fantasai> florian: have two keywords<br>
&lt;fantasai> florian: but inspired by how we dealt with color-gamut, if you match the "extreme high" value, you also match 'somewhat high' value<br>
&lt;fantasai> florian: Another possibility is to split into two MQ, one for prefers-high-contrast and one for prefers-low-contrast<br>
&lt;fantasai> florian: can ignore levels by using as boolean<br>
&lt;fantasai> florian: But it's more syntax, more typing<br>
&lt;fantasai> florian: and lose the "has contrast preferences" syntax of (prefers-contrast)<br>
&lt;fantasai> florian: So that's a summary of the issue and where we're at<br>
&lt;melanierichards> q+<br>
&lt;astearns> ack fantasai<br>
&lt;florian> fantasai: I agree that we should choose a syntax that makes it easy to not distinguish betwtween levels of high<br>
&lt;florian> fantasai: 3B is my favorite<br>
&lt;florian> fantasai: also, increase vs increased is hard to remember. How about "more" and "less"<br>
&lt;astearns> ack melanierichards<br>
&lt;fantasai> s/high/high so that authors can do that easily and correctly/<br>
&lt;fantasai> melanierichards: I think whichever syntax we go with, with keyword-based approach, makes it unclear from MQ how authors should respond to the query<br>
&lt;fantasai> melanierichards: what is low enough? what is high enough?<br>
&lt;fantasai> melanierichards: will have authors respond to preference in variable ways<br>
&lt;fantasai> melanierichards: e.g. prefers-reduced-motion, authors interpret as turning off all motion<br>
&lt;fantasai> melanierichards: so can have very blunt responses<br>
&lt;gregwhitworth> valid point melanierichards<br>
&lt;fantasai> melanierichards: would be nice to see precise contrast ratios in the syntax<br>
&lt;fantasai> florian: Do you feel users might have a common preference for a contrast ratio of 8 vs 12?<br>
&lt;fantasai> melanierichards: that level can come from ??<br>
&lt;fantasai> melanierichards: could look like WCAG increased contrast levels perhaps<br>
&lt;fantasai> melanierichards: but difference between someone who needs a little bit of a boost vs extremely high contrast<br>
&lt;AmeliaBR> I don't think exact ratios are necessarily helpful, but `increased` vs `maximum` is a reasonable description of the MacOS setting vs the default WHCM themes<br>
&lt;fantasai> astearns: ratios would allow authors to do math<br>
&lt;fantasai> melanierichards: also allows programmatic styling<br>
&lt;fantasai> florian: that would be a different thing<br>
&lt;fantasai> florian: this is a query, you get a yes or no<br>
&lt;fantasai> florian: if we want the number as a thing to do math on, should be an environment variable<br>
&lt;fantasai> astearns: I was meaning comparisons. you can decide at what level to respond<br>
&lt;fantasai> florian: hooking into WCAG is tricky also<br>
&lt;Rossen_> q<br>
&lt;fantasai> florian: because levels of contrast are different dependong on the size of the text<br>
&lt;fantasai> florian: MQ is too blunt to explore that kind of thing<br>
&lt;fantasai> florian: and we don't want to expose users to a bunch of sliders<br>
&lt;fantasai> florian: for body vs heading text etc.<br>
&lt;fantasai> florian: doesn't seem practical<br>
&lt;fantasai> florian: but if you want to effectively use as numbers, ??<br>
&lt;astearns> ack Rossen_<br>
&lt;fantasai> Rossen_: Whole topic of contrast and effective use through intended and various purpose<br>
&lt;fantasai> Rossen_: is a long and deep one<br>
&lt;fantasai> Rossen_: goes far beyond specifying a few colors in response to an MQ<br>
&lt;fantasai> Rossen_: In general, we should aim to provide capabilities to authors to continue to improve contrast<br>
&lt;gregwhitworth> florian: you can specify the keyword to be that of a contrast ratio that is above x:y<br>
&lt;fantasai> Rossen_: I also sort of sympathize with notion of involving at the very least Alice and James<br>
&lt;fantasai> Rossen_: but again, we may or may not end up with something as simple as higher vs lower<br>
&lt;fantasai> Rossen_: working with our own researches, contrast can be achieved in different ways to improve legibility<br>
&lt;fantasai> Rossen_: don't necessarily need contrast ratios in some bounds<br>
&lt;fantasai> Rossen_: can use various properties of color space to do that<br>
&lt;gregwhitworth> florian: and then potentially have some concrete tests of something that allow for an OS to map it accordingly. EG: What I see from MacOS it doesn't really impact text especially within the UA itself and as such could possibly not meet a contrast ratio of text but may for borders, etc<br>
&lt;fantasai> Rossen_: I think it's a great discussion, don't want to resolve on anything at this point<br>
&lt;gregwhitworth> florian: worth exploring<br>
&lt;fantasai> florian: one more thing, I'd like to add<br>
&lt;fantasai> florian: value in keeping it simple<br>
&lt;fantasai> florian: in part to make it easy for authors to understand what is going on<br>
&lt;fantasai> florian: and also a11y features which are not purely about a11y tend to get better usage and better response from authors<br>
&lt;fantasai> florian: preference for light on dark and dark on light flipping automatically on time of day, e.g.<br>
&lt;fantasai> florian: possible that UA could hook higher contrast mode when outside in bright light, lower in dark room or something like that<br>
&lt;fantasai> florian: there is nuance, but also value in simplicity<br>
&lt;fantasai> astearns: Tess suggested taking up on APAC call, happens to be next week, so hopefully Alice and James can join us<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 30 July 2020 16:53:59 UTC