[css-color-4] What if gradients with legacy colors *also* interpolated in Oklab by default?

[LeaVerou]

Right now, css-color-4 allows UAs to handle interpolation between legacy colors in gamma-encoded sRGB:

However, user agents may handle interpolation between legacy sRGB color formats (hex colors, named colors, rgb(), hsl() or hwb() and the equivalent alpha-including forms) in gamma-encoded sRGB space. This provides Web compatibility; legacy sRGB content interpolates in the sRGB space by default.

I wrote this as a may to give UAs the choice of not doing this, but so far implementations seem to have all done this.
We have accepted that we have to live with this wart because of webcompat, but I'm not sure we have sufficiently examined the implications of the opposite. Can we actually examine the web compat implications of doing away with this clause? What if we moved all color interpolation on the Web away from gamma-encoded sRGB?

There is precedent of changing rendering of existing content when the new way is universally better (text-decoration-skip, I'm looking at you), so this shouldn't be a non-starter, the bar is just high for what kind of changes are acceptable, and I'd argue this may pass that bar. Interpolating colors in Oklab never produces worse results (I challenge anyone who disagrees to find me an example where gamma-encoded sRGB interpolation produces better results, you can play with the colors here in Safari TP).

The only case I can think of where gamma-encoded sRGB interpolation is desirable is color pickers. However,

• the gradients in color pickers are only a visual aid, but the actual picked/displayed color would not be affected
• I think this would only affect RGB color pickers (like this), and most color pickers use a hue-based model (HSL, HSV, etc). I really struggled to find one that actually shows RGB visualizations. The hue-based ones are still implemented through segments of gamma-encoded sRGB interpolated gradients (since that was the only gradient available), but the segments are so small I don't believe there will be any difference.
• There should be wording in that spec that forbids UAs from implementing this without implementing the syntax to control interpolation space, so that authors can always revert to the previous behavior for the handful of cases where gamma-encoded sRGB interpolation is desirable.

It would be nice if gradients could just do the right thing by default without people needing to know about color spaces, and having to type in oklab in their gradients like a magic incantation until the end of time. 😕

Examples

red to lime:

red to aqua:

red to fuchsia:

aqua to fuchsia:

lime to fuchsia:

lime to blue:

blue to gray:

white to blue:

white to black:

[svgeesus]

(I challenge anyone who disagrees to find me an example where gamma-encoded sRGB interpolation produces better results, you can play with the colors here in Safari TP)

Thanks for the demo! I had expected it to also work in Chrome Canary 108 (with experimental flag), but it didn't which I found surprising.

[LeaVerou]

(I challenge anyone who disagrees to find me an example where gamma-encoded sRGB interpolation produces better results, you can play with the colors here in Safari TP)

Thanks for the demo! I had expected it to also work in Chrome Canary 108 (with experimental flag), but it didn't which I found surprising.

It appears to be parsing the syntax, but not actually applying it. I guess that must be temporary, otherwise it would break feature detection! @sesse could clarify.

[romainmenke]

I think this is very risky.

(I challenge anyone who disagrees to find me an example where gamma-encoded sRGB interpolation produces better results,

I don't think that is the right question.
All current usage should be assumed to be deliberate, matching some design/intention.

A preprocessor like PostCSS easily allows you to make in oklab a default without breaking backwards compat.

[Loirooriol]

Can you post a screenshot of the demo to see the better results? I tried WebKitGTK and in oklab parses but I don't see the difference.

[sesse]

I guess that must be temporary, otherwise it would break feature detection! @sesse could clarify.

I pulled out of CSS Color a long time ago, so I don't have anything to do with Chrome's implementation, sorry. (I ended up doing nesting instead.)

[LeaVerou]

Can you post a screenshot of the demo to see the better results? I tried WebKitGTK and in oklab parses but I don't see the difference.

I just added some to the first post.

[svgeesus]

So where are we on this? I saw @fserb saying that Chrome won't change gradients that currently interpolate in sRGB because backwards-compat is prioritized over better results.

[LeaVerou]

My understanding is that Chrome at some point tried interpolating in linear RGB by default and decided the backwards compat cost was too much; but that's very different than interpolating in OkLab…

Where is that comment by @fserb ?

[svgeesus]

@fserb wrote (in the context of which interpolation spaces should be allowed and whether to add intent-based names which might change over time):

I'm not convinced that we could do this: right now, we are not changing the default behavior from legacy-srgb, because that would break content. If we can't change gradients without breaking content, then having "intent-names" would be bad, because we would have the same problem when trying to change them in the future. I think this forces us out of intent and into explicit opt-ins.

[svgeesus]

My understanding is that Chrome at some point tried interpolating in linear RGB by default and decided the backwards compat cost was too much; but that's very different than interpolating in OkLab…

Here is a three-way comparison: srg-linear, srgb, and oklab

[svgeesus]

@fserb could yo confirm whether your backwards-compat concern was "we can't change to oklab to interpolate legacy" and not "we can't change to srgb-linear to interpolate legacy" because, as @LeaVerou pointed out, those are very different. I agree that interpolating in srgb-linear (which would be tempting if your colors are stored like that internally) would be a non-starter because it is very perceptually non-linear. While srgb and oklab are much more comparable, with srgb tending to be darker and a bit less saturated at the midpoint.