jensimmons
commented
2 years ago Closed jensimmons closed 1 year ago
jensimmons
commented
2 years ago 
css-meeting-bot
commented
2 years ago The CSS Working Group just discussed color functions and RCS.
fantasai
commented
2 years ago Sounded to me like RESOLVED: Not Yet
svgeesus
commented
2 years ago emilio: weinig commented that they'd prefer color-mix() to serialize with new color syntaxes unconditionally; i'm not opposed to that, but it requires us to have new colors to ship color-mix(). Makes me a little sad because it's more work to get this in the hands of authors, but they feel strongly about that.
I agree with @weinig on this
svgeesus
commented
2 years ago (I was on vacation for a week, sorry for the delay in responding)
How finished are the specifications for these features?
From Color 5:
color-contrast()
Pretty stable, has not changed much recently. Depends on (not very good, but stable) WCAG 2.1 contrast algorithm. Could be updated in the future to use the WCAG 3.0 algorithm as an explicit option, but that spec is far from setled and this future upgrade should not affect shipping it now.
color-mix()
Little churn now the syntax has stabilized. Depends on CSS Color 4 for color interpolation, which is also pretty stable.
Relative Color Syntax
Also pretty stable now.
From Images 4:
Non-sRGB interpolation of CSS Gradients
Depends on CSS Color 4 for color interpolation, which is also pretty stable.
They are currently part of Interop 2022... can browsers ship them? Or are the specs still changing too much?
The specs are not changing very much, mainly on points of detail or better wording. I firmly agree with these choices for Interop 2022 and hope that Chromium and Gecko are inspired to catch up to the fine implementation of these features in WebKit.
fantasai
commented
2 years ago Could be updated in the future to use the WCAG 3.0 algorithm as an explicit option, but that spec is far from setled and this future upgrade should not affect shipping it now.
My understanding is that the WCAG 3 algorithm is way better than the WCAG 2 algorithm, so making WCAG 3 the "opt-in" version would be kinda sad. How unstable is that algorithm itself (as opposed to WCAG 3 in general), and would it make sense to use it anyway?
svgeesus
commented
2 years ago How unstable is that algorithm itself (as opposed to WCAG 3 in general), and would it make sense to use it anyway?
That algorithm specifically is very contentious, is still being frequently modified, and does not seem to have consensus. People are deploying (various different revisions of) it in the wild.
LeaVerou
commented
2 years ago I will also point out that none of the editors of Color 5 (@svgeesus, me, @argyleink, @una) have been in that call, so it seems rather weird that the maturity of our spec was discussed and decided on in our absence. The reasonable thing would have been to punt it until at least ONE editor is on the call.
As Chris points out, most of these features are pretty stable, and have had experimental implementations in WebKit for a while. If you disagree, please point out specific issues, not just some general feeling. If you believe there are issues that have not been resolved but can't point to a GitHub issue, then create one! (e.g. I saw some concerns about currentColor — is there a GitHub issue about them??)
svgeesus
commented
2 years ago and have had experimental implementations in WebKit for a while.
Yes, in Safari since TP 122 so more than a year ago; and also ongoing implementation work in Gecko since Firefox 88. Both behind a flag. There is an associated Chromium issue, not clear if that means implementation is ongoing.
I agree there are specific issues being discussed, in particular regarding resolving color-mix() and color-contrast() or percentage normalization in color-mix(); in fact these are typical implementer feedback questions which one would expect to get in CR.
svgeesus
commented
2 years ago I saw some concerns about currentColor — is there a GitHub issue about them??
I think that is
which were somewhat simplified by the resolution to
jensimmons
commented
2 years ago I will also point out that none of the editors of Color 5 have been in that call, so it seems rather weird that the maturity of our spec was discussed and decided on in our absence. The reasonable thing would have been to punt it until at least ONE editor is on the call.
Sorry you weren't able to be there. We only talked about this for 2-3 minutes. Nothing was “decided”. I asked because we want to know if the specs are mature enough to start shipping.
Really it's a two part question:
The only decision here to make (in this issue) is for each browser team to decide if they want to ship now, given the responses to these questions. Or hold for further debate and potential upcoming changes.
If there are any issues left to debate or resolve, can we do so quickly? Let's remove any blockers, so we can get this technology into the hands of web developers.
svgeesus
commented
2 years ago I just proposed specific text for
and asked for it to be early on this week's agenda. So hopefully we can tie down the resolved form of these functions in a speedy fashion.
svgeesus
commented
2 years ago @jensimmons, sorry not to have responded to your earlier email, and also to this thread until later on - I was on vacation all last week.
For the editors, do you think browsers should start shipping?
Yes, soon. Two browsers already have these, behind a flag, which is already giving us some CR-like implementer feedback.
Or do you know of issues that need to be resolved first?
These issues are impacting implementation of the features that are part of Interop 2022 so I would like to see them resolved very soon:
Or edits you've been meaning to make?
One outstanding "needs edits" which again, relates to Interop 2022 areas:
Note that there are other issues which don't affect Interop 2022, like
svgeesus
commented
2 years ago Oh and in terms of spec stability, I just kicked off horizontal review which will need to be completed before Color 5 can advance to Candidate Rec.
Color 4 has already completed Horizontal Review and I expect it to move to CR fairly soon.
svgeesus
commented
2 years ago Noting this comment on Bugzilla from @emilio 11 days ago:
Bug 1770616 should get us to a pretty good state where I'd be ok shipping what we have.
Bug 1770616 was closed today
Myndex
commented
2 years ago Hi Chris and fantasai @svgeesus @fantasai
@fantasai said:
How unstable is that algorithm itself (as opposed to WCAG 3 in general), and would it make sense to use it anyway?
APCA is a candidate for WCAG 3 with the npm i apca-w3 package, but due to concerns over how long WCAG 3 may be, and the pressing need and strong demand for a functional perceptually uniform contrast solution, the scope has expanded. One part of the expansion is the Bridge-PCA, which is fully backward compatible to WCAG 2 contrast, as a literal drop in replacement.
@svgeesus said
That algorithm specifically is very contentious, is still being frequently modified, and does not seem to have consensus. People are deploying (various different revisions of) it in the wild.
I would like to address these statements, starting with the objective one, alleging frequent modification.
The rumor or claim that the APCA algorithm is being "frequently modified" are false.
The math and the base algorithm that generates the Lc contrast value HAS NOT CHANGED in well over a year.
And it was a subtle change from the constants in use when the WCAG 3 FPWD was released in January 2021.
// 0.98G-4g base version constants 02/15/2021:
exponents = { mainTRC: 2.4, normBG: 0.56, normTXT: 0.57, revTXT: 0.62, revBG: 0.65,};
colorSpace = { sRco: 0.2126729, sGco: 0.7151522, sBco: 0.0721750,};
clamps = { blkThrs: 0.022, blkClmp: 1.414, loClip: 0.1, deltaYmin: 0.0005,};
scalers = { scaleBoW: 1.14, loBoWoffset: 0.027,
scaleWoB: 1.14, loWoBoffset: 0.027, outFactor: 100.0,};Click to Enlarge
The "changes" in the link you posted to are NOT the algorithm, they related to separate UTILITIES such as for color string parsing or doing alpha blending. Those are supporting functions for developers to assist with integration into tools.
That repo, the apca-w3, was setup when I published it as an npm package, again to make integration easier for developers. It is a library of tools, but the main, contrast math, never changed, and I don't know why you'd have that impression, other than the three internet trolls that have been harassing me. But please don't listen to rumors by uninformed trolls.
One of the "changes" at the request of some developers, was simply to take the string parsing and put it in its own package, such that the APCA package was only the specific items unique to APCA, that's now in a package called colorparsley. The extent of these changes was to take the stable algorithm and publish on npm.
npm i apca-w3
npm i colorparsley
npm i bridge-pcaThe font lookup table(s) are separate, and part of Silver/Gold conformance guidelines, they are not the APCAlgorithm. And regardless, last year we developed a simplified conformance model to make things work "more like" WCAG 2, and it does not involve a lookup table, just a few levels:
There is a lot of discussion regarding conformance for WCAG 3, but that is not related to the APCA algorithm, rather, it is to things like "levels," or minimum font size — but that does not impact the readability contrast model that is APCA.
...That algorithm specifically is very contentious ....does not seem to have consensus...
What makes you say this? The three trolls that have been harassing me personally have attempted to spread rumors, I'd hope that such unsupported derision would be ignored. I have never heard anything reported as an actionable or functional fault. I'm not going to get into the chain of drama, but do extend the offer of a zoom chat to answer any such questions.
I do search regularly to unearth issues or complaints—the GitHub repo has been open since Sept. 2019, and early concerns have been addressed or adjusted for. Today, there has been significant growth and interest, including active development and integration into tools (the downside of which I'll get to in a moment).
There have been several positive peer or third party review articles — I have yet to find a negative one, but please let me know if there is an actual reservation in terms of the functioning or use of the method.
As you know this started with "thread 695" over three years ago and we worked very hard for two years in the visual contrast subgroup to develop a robust solution based on solid vision and readability science, and I've been plainly open about this, with the white papers and other documentation. Because it's been over an extended period, I realize that the information was not as ideally organized, so recently I created a catalog page of resources, articles, and documentation:
But to be very concise about it:
The algorithm evolved from established peer reviewed science: CIELAB, CIELUV, Fairchild's R-Lab, the Hunt model, CIECAM02, and the P.Barten contrast model, and also referencing Stevens, and plus the work of Maureen Stone (PARC, NIST), and Larry Ahrend (NASA).
The readability side of things (font lookup, levels, conformance guidelines) all come from Bailey/Lovie-Kitchin's readability research, and also G. Legge. I discuss this and the relationships to critical contrast and critical size in this thread on use cases and conformance models.
People are deploying (various different revisions of) it in the wild
This is annoying, and partly the fault of some Silver draft links persisting without indication that they are deprecated—another part of what appears to be some level of intentional obstructionism. I've been proactive in chasing these down, and working with developers. But I would love to hear about any tools claiming to be APCA compliant and not implementing it correctly.
This is the reason I set the time limited license, as a temporary measure to reign this nonsense in—but that has consequences, as it raised (unwarranted) concerns about the openSource future of it all.
The thing is Chris, APCA exploded in popularity in a way that completely caught me off guard. And it was its growing popularity that give rise to the "contentiousness"... apparently one author reviewing it told people they should "use it now" and to be absolutely clear, I had nothing to with with that statement. Nevertheless, people are tired of using something that does not work. And it's worse today, with the increasing popularity of Dark Mode, as WCAG 2 contrast math can not calculate for dark mode.
The "contentiousness" you may be referring to is the concerns over early adopters and rapidly growing popularity, which might answer your comment regarding consensus.
And I do have actions being taken to alleviate any concerns—hopefully having the main paper I've been working on published in the fall (ish) will resolve some of these questions.
Thank you for reading
Andy
svgeesus
commented
2 years ago @Myndex Thanks for the clarification regarding versioning and stability. In that case, please update your readme which gives a very different impression:
Current Version: 0.1.4 G (w3) beta 0.1.4 • May 27, 2022
(That is six days ago). If the constants are identical to 0.98G-4g base version constants 02/15/2021 then you should clearly state this, in the readme.
CHANGE for 0.1.1: NEW!! Alpha channels! AdobeRGB!!
That change is undated, and I can't find what TRC or chromaticities you are using. Are these also in 0.98G-4g base version?
CHANGE for 0.1.0: NEW! displayP3!
Ditto.
However, regarding the substance of this issue, it seems clear that:
color-contrast() should continue to reference the WCAG 2.1 algorithm, flawed as it is, since that is the basis for current usage and is mandated in some legal contextscolor-contrast(), because
Myndex
commented
2 years ago Hi Chris @svgeesus
Thanks for the clarification regarding versioning and stability. In that case, please update your readme which gives a very different impression:
Done. Thank you for pointing this out. And please let me know of any other concerns, misunderstandings, or rumors that have arisen here regarding APCA and related.
color-contrast()_However, regarding the substance of this issue, it seems clear that:_
- CSS Color 5
color-contrast()should continue to reference the WCAG 2.1 algorithm, flawed as it is, since that is the basis for current usage and is mandated in some legal contexts
If the WCAG 2 math is the only useable math at this time, then color-contrast() is not a useable function, and should not be advanced into use. It will have a damaging effect on accessibility.
The only reason that the WCAG 2 contrast math and SCs managed to stumble along for 15 years is that it is like "a broken clock is right twice a day" — pure conformation bias. A skilled designer is going to pick readable colors in the first place. If the "broken clock" says they pass, no one raises an eyebrow. And so it have been for 15 years.
But the FACT is that WCAG 2 contrast ONLY WORKS when the background is very light or white. Now with DARK MODE, gaining in popularity, the failings of WCAG 2 contrast are ever more clear.
And if you take the eyes of the designer out of the equation by adding this function, then significant unintended consequences will result. A color-contrast()function using WCAG 2 math will happily create unreadable colors. And this is not good.
Here is an example: Each column WCAG 2 is the exact same contrast ratio from top to bottom. Notice how as a color pair gets darker, that WCAG 2 contrast reports a passing grade for unreadable color pairs.
The claim that WCAG 2 contrast is "legally mandated" is not s persuasive reason to include a less-that-functional extension of a not-fit-for-purpose hand-wavy pseudoscience guideline.
I've examined the laws, and such a statement is misleading. In the US, WCAG 2 is NOT mandated by the ADA, nor is there any federal case law that makes such a holding (and note that Winn-Dixie was VACATED by the 11th district court).
In the US, the 508 applies to Federal-related entities only. And even here, the 508 has two important exemptions:
1) If something is not "commercially available" then it does not have to meet 508. 2) For any WCAG 2 SC, an "alternate" means may be used, so long as it provides equal or better accessibility.
This is not a mandate to use WCAG 2, it is a mandate to be accessible.
This point is echoed in the laws I've examined in other parts of the world as well—even if they specifically mention WCAG 2 they have similar exception clauses. Beyond that I have gathered ample evidence proving that APCA provides better and more accessible contrast guidance, and APCA has been reviewed by third parties see the review section here.
AFAIC: It is legally negligent to continue to use methods that have been shown to be faulty when improved alternates are available.
If there remains an actual concern about being "backwards compatible" to WCAG 2, then there is BRIDGE-PCA which is entirely backwards compatible as a literal drop-in replacement for the WCAG 2 math. npm i bridge-pca
color-contrast() until such time as an appropriate perceptually uniform math is used. Until then, it is negligent to allow it to be adopted as a usable function using WCAG 2 math.
- another function could be added, for WCAG 3, rather than extending
color-contrast(), because
- foreground and background need to be explicitly identified, rather than treated as interchangeable
- the font size and font-weight dependencies also need to be integrated
Neither of these is true, and there exists versions that are a drop-in backwards compatible replacement for WCAG 2 math.
color: and border-color: vs background-color: no further identification is needed.
color: color-contrast( 90 #ddd #222 auto );
#ddd and #222 would be checked against the color that is currently defined as the backgrund color.auto would provide either black or white, which ever is "best"background-color: color-contrast( 90 #ddd #222 auto );
color:, or if none the next border-color:Also, Bridge-PCA in "WCAG mode" ignores polarity if that is really an issue (??) but as outlined it should not be. And further it should not be because if you are developing something NEW, then considering it is well known that there is a polarity difference in perception, then any new method should be considering that.
As proposed, color-contrast() is taking a rusty petrol engine from a Model T-Ford and crossing-fingers hoping it'll work in a Tesla.
Also, I am at your disposal for answering any questions and addressing any concerns you may have regarding APCA or future guidelines in this area.
Thank you for reading,
Andy
stordahl
commented
2 years ago I completely agree with the arguments presented by @Myndex - as a developer & designer, I have had WCAG 2 color contrast functions fail me numerous times in my career when attempting to create accessible experiences. Shipping an accessibility feature, like color-contrast(), too fast does not help make the web more accessible, and is actively working against that goal.
At the end of the day, contrast algorithms based on perception, like APCA, are clearly the way forward, and introducing a feature like color-contrast() with WCAG 2 color contrast algorithms is a step backwards for the platform. I think Tim put it best when he said...
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. – Tim Burners-Lee
svgeesus
commented
2 years ago But the FACT is that WCAG 2 contrast ONLY WORKS when the background is very light or white. Now with DARK MODE, gaining in popularity, the failings of WCAG 2 contrast are ever more clear.
I do find this particular failing of the WCAG 2.1 algorithm to be especially troubling.
css-meeting-bot
commented
2 years ago The CSS Working Group just discussed Is color-contrast() ready to ship?, and agreed to the following:
RESOLVED: Move color-contrast() to CSS Color Level 6css-meeting-bot
commented
2 years ago The CSS Working Group just discussed Ready to Ship Color Stuff, and agreed to the following:
RESOLVED: color-mix() and gradient interpolation are ready to shipRESOLVED: colr-mix() and gradient non-sRGB interpolation are "ready to ship", add to Snapshot 2022svgeesus
commented
2 years ago From Color 5:
From Images 4, via Color 4:
Myndex
commented
2 years ago Thank you Chris, Lea, Fantasi, Adam, et alia @svgeesus @LeaVerou @fantasai @argyleink
Thank you for taking the time to discuss this, based on all related timelines for normative changes in this area, I think deferment is the best in the interim.
I see the mention of a "black/white flipper" — even that is not always trivial, as the "middle contrast" value is not "middle grey". I have a repo and a CodePen with examples/demos: Fancy Font Flipping
I'd suggest the simple solution posed below, BUT flipping at a correct middle contrast would not necessarily pass WCAG 2, as the contrast center for WCAG 2 math is ~18Y (#767676), which is a principal part of that problem.
While 18% is a decent middle for large patches of reflected colors, in the context of high spatial frequency stimuli (text) the middle contrast is substantially higher. And as result the "flip point" is higher, as we want to flip at middle contrast, which is around 34Y to 42Y. But we also find that there really is not an ideal middle, as the total contrast range of an typical sRGB display is insufficient to have both white and black text at optimum readability contrast for small fonts (like body text) at some middle point (this is assuming the Bailey/Lovie-Kitchin critical contrast and 20x contrast reserve).
I.e. at 100Y we have black text, as the bg gets darker, at 42Y or so, small black text starts getting harder to read, but flipping to white isn't much help either. With a 0Y bg, we have white text, but as the bg gets brighter than 34Y ish, we're loosing readability with small text. So in this 34-42Y range, you could kinda have either black or white text, but you'd want to increase the size or weight so that it's large enough for this lowered contrast range.
This discussion regards readability only which implies luminance only — Also, my statements above are directed toward columns of body text smaller than 18px. At 24px and above you can more or less say "flip point is 37Y".
In this discussion I am using luminance Y and not a perceptual lightness measure deliberately: if you rest upon a single point to flip from black or white, there's no need to transit into any other space, just determine the appropriate offset for the relative luminance value, and this is useful enough for a basic pair of colors. It all gets much more tricky when you are doing 3-way and more inputs, and/or adding in hue/chroma considerations, in which case a simple flip point like this would be insufficient.
And finally: as monitor peak white levels soar higher, it is desirable to not have full white anything for things you're staring directly at. Both backgrounds or text are not well presented at #ffffff... light text might ideally be limited at #eeeeee.
In the present situation, even a simple B&W flipper would cause conflicts with the existing WCAG 2 guidelines, indicating again the importance of corrections there. And even a simple flipper has "bonus unexpected results" that need consideration.
Thank you for reading,
Andy
svgeesus
commented
2 years ago I see the mention of a "black/white flipper" — even that is not always trivial, as the "middle contrast" value is not "middle grey"
Agreed, and I argued as such on the call.
svgeesus
commented
2 years ago I.e. at 100Y we have black text, as the bg gets darker, at 42Y or so, small black text starts getting harder to read, but flipping to white isn't much help either. With a 0Y bg, we have white text, but as the bg gets brighter than 34Y ish, we're loosing readability with small text. So in this 34-42Y range, you could kinda have either black or white text, but you'd want to increase the size or weight so that it's large enough for this lowered contrast range.
Well put.
At 24px and above you can more or less say "flip point is 37Y"
For those not as familiar, this is the luminance Y on a 0 to 100 scale. So expressed in terms of CSS syntax, with a D65 white, that would be color(srgb-linear 0.37 0.37 0.37) which is color(xyz-d65 0.352 0.37 0.403), oklab(71.8% 0 0) or rgb(64.2% 64.2% 64.2%)
svgeesus
commented
2 years ago Re-opening since we dropped the ball on Relative Color Syntax. Jen asked about RCS in the initial post in this issue; there was a brief discussion on May 25 but nothing was decided as none of the editors were on the call.
Interop2022 is considering dropping it because of lack of signals from CSSWG.
svgeesus
commented
2 years ago @jensimmons said
Relative color syntax was not on that list because it was deemed not ready. The recommendation was that browsers should not ship relative color syntax.
There wasn't a resolution that it was not ready. Nor was there a resolution that it was ready. I re-opened the issue because the question you asked didn't really get much discussion nor a clear resolution. There was a passing mention by @emilio that there was only one implementation (in WebKit) and they "would like more feedback on relative color syntax".
Maybe there is more feedback. There aren't open issues. Maybe issues need to be filed?
josepharhar
commented
2 years ago I was working on color-contrast() in chromium and I'm wondering what the status is to change/ship it. It seems like there was some feedback about color-contrast earlier in this issue which I didn't closely follow. Have there been any other issues created to talk about color-contrast? Is the consensus to get rid of it...?
bramus
commented
2 years ago Have there been any other issues created to talk about color-contrast? Is the consensus to get rid of it...?
Please refer to https://github.com/w3c/csswg-drafts/issues/7553, which is a meta/umbrella issue for all color-contrast() issues
LeaVerou
commented
2 years ago Have there been any other issues created to talk about color-contrast? Is the consensus to get rid of it...?
Please refer to #7553, which is a meta/umbrella issue for all
color-contrast()issues
The summary being: No, please don't implement this, the spec is very much in flux, but hopefully we should have an implementable subset soon.
svgeesus
commented
1 year ago Closing since all the listed features are now either:
color-mix(), from colorspace)color-contrast())
How finished are the specifications for these features?
From Color 5:
From Images 4:
They are currently part of Interop 2022... can browsers ship them? Or are the specs still changing too much?