[css-color-5][css-images-4] Are these features ready to ship?

[jensimmons]

How finished are the specifications for these features?

From Color 5:

• color-contrast()
• color-mix()
• Relative Color Syntax

From Images 4:

• Non-sRGB interpolation of CSS Gradients

They are currently part of Interop 2022... can browsers ship them? Or are the specs still changing too much?

[jensimmons]

Spec links:
https://drafts.csswg.org/css-color-5/#colorcontrast
https://drafts.csswg.org/css-color-5/#color-mix
https://drafts.csswg.org/css-color-5/#relative-colors
https://drafts.csswg.org/css-images-4/#linear-gradients

Relevant: #7302

[css-meeting-bot]

The CSS Working Group just discussed color functions and RCS.

The full IRC log of that discussion

<TabAtkins> Topic: color functions and RCS
<bkardell_> astearns: did we talk about a day to meet up next week on selectors 4? doing it on the list?
<TabAtkins> jensimmons: These are all part of Interop2022, are they ready to ship? ARe specs good enough, or are they unstable?
<astearns> github: https://github.com//issues/7310
<emilio> q+
<astearns> ack em
<TabAtkins> emilio: I'd love to ship some of these, but there's a lot of open questions
<TabAtkins> emilio: I don't think there's any complete impl of these features.
<TabAtkins> emilio: WebKit implements a bunch, but doesn't support currentcolor at all. Gecko also has trouble with currentcolor.
<TabAtkins> emilio: There's some question about resolution timing taht I filed last week.
<TabAtkins> emilio: So don't think things are quite ready to ship yet.
<TabAtkins> jensimmons: So question really is if the spec is gonna significantly change after shipping happens.
<TabAtkins> jensimmons: I think your issue highlights that some things still need to be defined. Maybe we can make this a prio to finish the spec?
<TabAtkins> emilio: Think that would be great. Haven't been working actively, been spending free time on it.
<TabAtkins> emilio: I can tell from Firefox usage - we enabled color-mix() in trunk and it's used extensively, over a thousand uses immediately.
<TabAtkins> emilio: So I think it would be great to prio.
<TabAtkins> astearns: So we're at time, please put your thoughts in that issue.
<TabAtkins> astearns: AGree I'd like to see one complete impl before making the decision that it's shippable.
<TabAtkins> fantasai: Sounds like this isn't ready to ship *yet*, but we should try to get it there soon.
<TabAtkins> emilio: What I"d love is to avoid interdependencies on these features.
<TabAtkins> 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.
<TabAtkins> emilio: It'd be great to work out a way to minimize interdependencies so we can ship incrementally.

[fantasai]

Sounded to me like RESOLVED: Not Yet

[svgeesus]

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]

(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]

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]

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]

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]

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]

I saw some concerns about currentColor — is there a GitHub issue about them??

I think that is

• [css-color-5] What should the behavior of the CSS Color 5 color functions be when passed currentcolor as <color>  #6168
• [css-transitions] Define interpolation of the currentcolor keyword #445

which were somewhat simplified by the resolution to

• [css-color] [css-color-adjust] Make system colors fully resolve (but flag they were system colors) thus reversing the resolution of #3847 #6773

[jensimmons]

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:

• For the editors, do you think browsers should start shipping? Or do you know of issues that need to be resolved first? Or edits you've been meaning to make?
• For other implementors — do you have any objections to the current specifications? Anything you want to change or debate further before we all start shipping?

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]

I just proposed specific text for

• [css-color] Resolving color-mix() #7302

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]

@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:

• [css-color-5] Clarify serialization of color-mix() #6206
• [css-color-5] What should the behavior of the CSS Color 5 color functions be when passed currentcolor as <color>  #6168
• [css-color] Resolving color-mix() #7302

Or edits you've been meaning to make?

One outstanding "needs edits" which again, relates to Interop 2022 areas:

• [css-color-5] Gamut mapping in HSL/HWB #7107

Note that there are other issues which don't affect Interop 2022, like

• [css-color-5] [cssom-1] Exposure of @color-profile in CSSOM #7151

[svgeesus]

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]

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]

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.

Stability

The rumor or claim that the APCA algorithm is being "frequently modified" are false.

These demurrers claiming frequent modification are not true.

The math and the base algorithm that generates the L^c contrast value HAS NOT CHANGED in well over a year.

The last change to the constants and exponents was February 15th 2021

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-pca

Font Lookup Tho

The 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:

• L^c90 • Preferred level body text, similar to ISO 10:1
• L^c75 • Minimum level for body text, "Sort of" like the old WCAG 7:1.
• L^c60 • Minimum level for readable content text, "Sort of" like 4.5:1.
• L^c45 • Minimum level for large (36px+) such as headlines. "Sort of" like 3:1.
• L^c30 • The absolute minimum for non-content text (such as disabled).

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.

Contentious Consensus

...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:

git.myndex.com

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.

Errant Versions

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.

WHAT HAPPENED

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]

@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:

• 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
• 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

[Myndex]

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.

on 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

I can not agree.

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.

Not Fit For Purpose

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.

Legal Questions

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

Formal Objection

As a result, I object to the inclusion of 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.

Regarding Integration

• 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.

Explicit ID

• Explicit identification already exists in CSS: it is color: and border-color: vs background-color: no further identification is needed.
  • On that note, the currently stated implementation has additional concerns in that (as I understand it) it requires listing both the colors? It seems to me:
    • A useful implementation would determine the adjacent color to be compared to intrinsically. e.g.:
    • color: color-contrast( 90 #ddd #222 auto );
      • In this case, the colors #ddd and #222 would be checked against the color that is currently defined as the backgrund color.
      • The result is using the first one in the list to meet Lc90,
      • And if none, then auto would provide either black or white, which ever is "best"
      • And ideally, if neither black or white achieves the needed contrast (a real consideration) then the relevant background color would be adjusted until the closest ( white or black ) did succeed.
    • background-color: color-contrast( 90 #ddd #222 auto );
      • In this case would look for the next element with color:, or if none the next border-color:
  • Otherwise, the current implementation does not solve any problem and only creates new ones.

Size and Weight

• No, font size and weight does NOT need to be integrated to use APCA, as they are not dependencies for the algorithm that generates the Lc value.
  • APCA only requires the stimulus color and the background color to generate the Lc value.
  • The Lc value perception curves are based on the maximum spatial frequency for the given contrast, as assessed by the contrast-matching experiments, meaning that stimulus consideration is integral.
  • The font size and weight are conformance specifications, and they've always been separated to keep the function of the APCA Lc value calculation as simple, flexible, and integratabtle as possible.

Drop-In and Polarity

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.

TL;DR

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]

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]

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]

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 6

The full IRC log of that discussion

<emilio> topic: Is color-contrast() ready to ship?
<emilio> github: https://github.com//issues/7310
<chris> We believe the color-contrast() function needs significant modification to make it future-compatible and to make it work as intended, and propose deferring this feature to CSS Color Level 6 so that we can work on it without holding back the rest of CSS Color 5.
<fantasai> scribe+
<fantasai> chris: Had a breakout about color-contrast(), partly prompted by an FO about using WCAG2.1's algorithm
<fantasai> chris: That is known to give bad results frequently, particularly in dark mode
<fantasai> chris: figures of around 40% being wrong
<fantasai> chris: There's work to develop a new one, but not ready, not normatively referenced in WCAG3
<fantasai> chris: Also complaints about syntax and so on
<fantasai> chris: On the one hand browsers have it working reliably, on the other hand it often give sthe wrong answer
<fantasai> chris: We don't want to ship something that is interoperable, but is harmful to the Web platform
<fantasai> chris: So we want to shift this to the next level
<lea> q?
<lea> q+
<fantasai> astearns: Any arguments for not deferring?
<astearns> ack lea
<fantasai> lea: I completely agree with deferring it, unfortunately
<fantasai> lea: one thing from breakout we wanted feedback from implementers
<fantasai> lea: breakbout was me, Chris, Adam, and fantasai
<fantasai> lea: Would help if we could ship color-contrast() without a specified algorithm, could use the best available algorithm
<fantasai> lea: we're concerned that implementers would be against doing something that changed over time
<fantasai> https://github.com//issues/7361
<argyle> this? https://github.com//issues/7361
<fantasai> fantasai: if we went this route, could ship a subset of functionality sooner
<fantasai> fantasai: but need to make some syntactic changes to make future-compatible first
<chris> q+
<smfr> q+
<fantasai> astearns: I would worry slightly about defaulting to best available, and then ppl expecting current results, and then getting different results when have a better algorithm
<fantasai> lea: yes, that's the worry
<fantasai> chris: Yes, concern that it will continue to do what it did earlier
<fantasai> chris: Also the target contrast values have different meanings depending on the contrast algorithm
<fantasai> chris: so I don't think it makes sense to use a mystery algorithm that works differently later on
<astearns> ack chris
<fantasai> chris: it's not small progressive change, it's a major change
<astearns> ack smfr
<fantasai> smfr: I agree with those concerns
<fantasai> smfr: also don't want push the burden of choosing algorithms to web authors
<astearns> ack fantasai
<emilio> fantasai: I think if we wanna push for something sooner we'd need to go for something very minimal
<lea> q?
<jensimmons> q+
<emilio> ... if it solves things like github labels or so then good, but everything else would need to be deferred
<emilio> ... if that's something that people thing it's important (having black / white text) maybe we can have a very minimal function
<fantasai> chris: even "black or white on this color", WCAG gets wrong substantially a lot of the time
<fantasai> chris: I don't think it's worth doing
<astearns> ack jensimmons
<lea> q+
<fantasai> jensimmons: it's very hard to teach authors that what they were doing with a thing earlier, and failing them, it's very hard to unteach that
<fantasai> jensimmons: we might have a year of it working poorly, ppl say "this sucks, don't use it" for the next 5 years
<chris> s/WCAG gets/WCAG 2.1 gets/
<fantasai> jensimmons: super hard to get people to change their habits
<astearns> ack lea
<fantasai> lea: I think the idea behind shipping minimal white/black is not that WCAG is good enough, but it is more likely to be able to change it
<fantasai> lea: I think that was the thinking behind it
<fantasai> fantasai: Yes, we would swap in better algorithm as soon as we have it
<fantasai> astearns: putting aside whether to do simple version at all, sounds like we generally agree that the more complex color-contrast() function needs to be deferred
<fantasai> astearns: can we resolve on that?
<fantasai> RESOLVED: Move color-contrast() to CSS Color Level 6
<fantasai> astearns: I think we could continue discussing possibility of smaller subset of functionality in an issue
<fantasai> astearns: but might be better to continue work on the function that we want, and put that out as quickly as we can
<fantasai> chris: Now that we've resolved that, my focus is on remaining bits in Interop 2022
<fantasai> chris: color-mix(), interpolation, etc.
<fantasai> chris: so let's move on to other issues

[css-meeting-bot]

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 ship
• RESOLVED: colr-mix() and gradient non-sRGB interpolation are "ready to ship", add to Snapshot 2022

The full IRC log of that discussion

<fantasai> Topic: Ready to Ship Color Stuff
<fantasai> chris: Would love to see the interpolation for gradients shipping, can we resolve and say it's ready to ship?
<fantasai> chris: color-mix(), relative color syntax, and interpolation of gradients in non-RGB color spaces
<fantasai> github: https://github.com//issues/7310
<fantasai> astearns: no more issues on color-mix()?
<fantasai> chris: no
<emilio> q+
<fantasai> astearns: relative color syntax?
<fantasai> chris: No, and ppl liked it. I talked about it last week
<fantasai> astearns: interpolation of gradients?
<fantasai> chris: Uses the same syntax as color-mix(), "in colorspace"
<fantasai> astearns: Any objections to marking these ready to go?
<astearns> ack emilio
<fantasai> emilio: So, color-mix() I'm fine saying current spec is shippable. We've gone through it a lot
<fantasai> emilio: The gradient one is relatively straightforward, would love to sanity-check it but seems reasonable assuming interpolation token gets preserved everywhere and no fancy computed style shenanigans, just only affects rendering
<fantasai> emilio: about relative color syntax, less enthusiastic because only one implementation
<fantasai> emilio: and their implementation seems to have same interop concerns as color-mix() where we had differences between WebKit / gecko
<fantasai> emilio: so not so sure about it ready to ship
<fantasai> astearns: we should have a high bar to say ready to ship, regardless of where spec in the process
<fantasai> [discussion about relative color syntax]
<fantasai> emilio: keep the token in specified and computed style, only affects rendering
<fantasai> emilio: if so, that seems reasonable
<fantasai> emilio: I think straigthforward enough, doesn't need super deep review
<fantasai> emilio: relative color syntax is trickier
<fantasai> chris: gradient is doing color-mix(), just doing it in all possible percentages. It's the same calculation
<fantasai> emilio: think it's probably fine. I would like more feedback on relative color syntax
<fantasai> emilio: but gradient interpolation seems straightforwad
<astearns> ack fantasai
<emilio> scribe+
<emilio> fantasai: happy with emilio's proposal to resolve on color-mix() + gradients but not yet on relative colors
<fantasai> astearns: declare color-mix() and non-rgb gradient interpolation as ready to ship
<fantasai> astearns: objections?
<chris> high five!
<emilio> RESOLVED: color-mix() and gradient interpolation are ready to ship
<fantasai> RESOLVED: colr-mix() and gradient non-sRGB interpolation are "ready to ship", add to Snapshot 2022

[svgeesus]

From Color 5:

• color-contrast()
• color-mix()
• Relative Color Syntax

From Images 4, via Color 4:

• Non-sRGB interpolation of CSS Gradients

[Myndex]

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.

Flipper

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.

AS SUCH:

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]

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]

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]

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]

@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]

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]

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

[LeaVerou]

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]

Closing since all the listed features are now either:

• cleared to ship (color-mix(), from colorspace)
• cleared to ship in #7978 (Relative Color Syntax)
• Not at all ready (color-contrast())