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