contrast-ratio() #7730
Labels
Comments
|
The CSS Working Group just discussed The full IRC log of that discussion<fantasai> Subtopic: Contrast Ratio<chris> github: https://github.com//issues/7730 <fantasai> matatk: not proposing to resolve all issues right now <fantasai> ... wanted to use our F2F time to get background <fantasai> ... what's the use case for this function? <Rossen_> ack chris <fantasai> chris: Dropped link to the issue <fantasai> ... where I gave an introduction to what we want to do here <fantasai> ... if you just have a single stylesheet, no variables, just light mode, don't need anything special <fantasai> ... everything is constant <fantasai> ... but if you have theming and customization, and stylesheets merged from multiple teams <fantasai> ... it will work out for you <fantasai> ... previously, this was all done by eye <fantasai> ... they chose contrast by eye, threw through a checker to be sure <argyle> also, user's bring preferences to the page: prefers-contrast (less, more, etc) <fantasai> ... here, not necessarily have human intervention <fantasai> ... but need to know that it will check out <fantasai> matatk: I thought you as the author still have to give colors to choose from and isn't that deterministic <fantasai> ... but you said it would be from variables <fantasai> ... wouldn't you still have to know which custom properties would be applicable? <fantasai> chris: yes, and the list that you give is in priority order <fantasai> ... also one of the open issues is allowing that list to be empty <fantasai> ... and if empty, it gives you a color: either white or black, whichever more contrasty <iank_> note - something these lists colors are generated from a user provided image for example. <fantasai> ... but if you want to pick a target contrast, then willl look for that <fantasai> chris: other big issue open atm is WCAG2 has a contrast algorithm which gives a lot of false positives and false negatives <fantasai> ... and we want to do btter <fantasai> ... I've implemented a bunch of contrast algos in JS so ppl can play with it <chris> https://colorjs.io/docs/contrast.html <fantasai> matatk: As side project, I had to write a functio nthat gives white or black from bgcolor <fantasai> ... so that's very helpful <fantasai> ... we'll follow the discussions and offer what advice we can <fantasai> janina: WCAG's color contrast rule is problematic in many ways <fantasai> ... including that some ppl don't do well with very high contrast, as you noted <fantasai> chris: It used to point to obsolete draft of sRGB, now it's updated <fantasai> janina: Plan to be smarter in 3, but quite a ways out, so time to get it smarter <fantasai> ... would be willing cooperators in that <Rossen_> q? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Motivation
For a single stylesheet which is all light-mode, has no color changes between mobile and desktop, and take no account of things like per-user customization or forced color mode, there is no need for color-
contrast()because it is a static, constant expression that returns a constant result.Once we have dark mode and light mode; once there are multiple stylesheets from different authors being combined in varying ways; once CSS variables are being extensively used - then the value of a dynamic unction like
color-contrast()becomes more evident. This explains why web developers at CSS conferences, for example, have been so enthusiastic about it.However, significant work is needed, as the simple luminance contrast function from WCAG 2.1 has significant issues with predictive accuracy. In the past, where static colors were chosen by eye and WCAG compliance run on that set just to verify, this was less of an issue. With developers relying on automatic selection because the number of combinations is not known ahead of time, the importance of a good algorithm for predicting the readability and legibility of text is greatly increased.
The text was updated successfully, but these errors were encountered: