[csswg-drafts] [css-color-4] What if legacy colors *also* interpolated in Oklab by default? (#7948)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-4] What if legacy colors *also* interpolated in Oklab by default? ==
Right now, [css-color-4](https://drafts.csswg.org/css-color-4/#interpolation-space) 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()](https://drafts.csswg.org/css-color-4/#funcdef-rgb), [hsl()](https://drafts.csswg.org/css-color-4/#funcdef-hsl) or [hwb()](https://drafts.csswg.org/css-color-4/#funcdef-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](https://codepen.io/leaverou/pen/dyKbavR)).

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](https://play.google.com/store/apps/details?id=com.edugameapp.rgbcolorpicker&hl=en_US&gl=US)), 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. 😕

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7948 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 24 October 2022 15:05:39 UTC