Repository navigation
[css-color-4] What if gradients with legacy colors *also* interpolated in Oklab by default? #7948
Description
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:
Activity
svgeesus commentedon Oct 24, 2022
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 commentedon Oct 24, 2022
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 commentedon Oct 24, 2022
I think this is very risky.
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 oklaba default without breaking backwards compat.Loirooriol commentedon Oct 24, 2022
Can you post a screenshot of the demo to see the better results? I tried WebKitGTK and
in oklabparses but I don't see the difference.sesse commentedon Oct 24, 2022
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 commentedon Oct 25, 2022
I just added some to the first post.
svgeesus commentedon Jan 31, 2023
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 commentedon Jan 31, 2023
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 commentedon Jan 31, 2023
@fserb wrote (in the context of which interpolation spaces should be allowed and whether to add intent-based names which might change over time):
svgeesus commentedon Jan 31, 2023
Here is a three-way comparison: srg-linear, srgb, and oklab
svgeesus commentedon Feb 7, 2023
@fserb could yo confirm whether your backwards-compat concern was "we can't change to
oklabto interpolate legacy" and not "we can't change tosrgb-linearto interpolate legacy" because, as @LeaVerou pointed out, those are very different. I agree that interpolating insrgb-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. Whilesrgbandoklabare much more comparable, withsrgbtending to be darker and a bit less saturated at the midpoint.romainmenke commentedon Feb 7, 2023
@svgeesus can you place srgb and oklab next to each other?
Placing a larger difference in between doesn't present the proposed change accurately.
35 remaining items
tabatkins commentedon Feb 21, 2025
If the WPTs have remained testing the old, now incorrect behavior, then I'm not surprised that browsers haven't followed the spec. Those need fixing.
Gingeh commentedon Feb 21, 2025
Despite being a pain to implement, I would personally be in favour of keeping the existing sRGB + oklab behaviour. This is primarily motivated by a gradient I found in a preexisting test page which appears much more "washed-out" when automatically changed from srgb to oklab:
svgeesus commentedon May 27, 2025
So we (still) have two options
[-][css-color-4] What if legacy colors *also* interpolated in Oklab by default?[/-][+][css-color-4] What if gradients with legacy colors *also* interpolated in Oklab by default?[/+]svgeesus commentedon Jun 4, 2025
This option amounts to reverting this edit and note that, cautiously, I made the edit using commenting-out rather than deletion.
If we go that way, I would argue for not restoring the previous text that started with:
because otherwise the spec is less testable (and also because no user agent did that).
css-meeting-bot commentedon Jun 4, 2025
The CSS Working Group just discussed
[css-color-4] What if gradients with legacy colors *also* interpolated in Oklab by default?, and agreed to the following:RESOLVED: Revert change to make all gradients interpolate in OKL by defaultThe full IRC log of that discussion
<astearns> ack ChrisL<fantasai> ChrisL: unfortunate situation that we took a resolution, but no browsers updated and WPTs test the current behavior
<fantasai> ChrisL: Two options
<jensimmons> What is the "reasonable proposal"?
<jensimmons> Can you summarize?
<fantasai> ChrisL: 1. we get implementers to say they're interested in doing this -- because so far we get people who are not happy with the proposed behavior
<fantasai> ChrisL: 2. we revert the resolution to match implementations and WPT
<fantasai> ChrisL: The thing we already have agreement on, and spec said for 18 months, is that all interpolation happens in OKLab unless you override
<fantasai> ChrisL: this means all interpolation changes, possibly for the better, but in any case it changes
<fantasai> ChrisL: I'd like us to either really do that, or really not do it
<fantasai> weinig: Implementing what's in the spec is easy. Most browser add additional checks for new vs old colors.
<fantasai> weinig: One challenge is that it will be a perf regression, at least for WebKit, to use OKL, since sRGB is much more optimized
<fantasai> weinig: so gradients will regress a little bit without special graphics backend. So that's one concern.
<fantasai> weinig: Another concern is changing websites
<smfr> q+
<ChrisL> q+ to say the main issue I see is unwillingness for backwards compat
<ydaniv> q+
<ChrisL> q-
<fantasai> weinig: That might be OK, but a bit hesitant to change all gradients that have ever existed on the Web
<astearns> ack smfr
<fantasai> smfr: Agree with Sams' perf concerns, and concern wrt legacy behavior
<lea> q?
<fantasai> smfr: Especially those that expect pixel-perfect behavior
<fantasai> smfr: e.g. iCloud docs
<lea> q+
<fantasai> smfr: so I think this does need to be opt in
<fantasai> weinig: No gradient will ever be pixel perfect, because by definition have dithering
<fantasai> weinig: but intention perfect
<fantasai> weinig: keynote document on mac, gradient renders different on mac and on web because we change interpolation
<fantasai> weinig: that would be unfortunate
<astearns> ack ydaniv
<jensimmons> q+
<ChrisL> q+ to say we have some wpt bugs because of dithering (which is allowed) but test reference assumes no dithering
<fantasai> ydaniv: although this is probably for the best, things like this could trigger CI failing when they update browser versions and suddenly screenshots and test tooling break randomly everywhere there's a gradient
<fantasai> ydaniv: I'm not sure how much that is a problem
<fantasai> ydaniv: sometimes happens because things change, but something to note
<fantasai> weinig: because gradients are this weird thing, they already break screenshot-based CI because they often have random or hardward-specific dithering
<fantasai> weinig: so all the places where could change, this is one with wiggle room
<fantasai> weinig: so if ppl have error bars, this might expand past
<astearns> ack lea
<TabAtkins> Tho, again, screenshot tools that allow specifying color-shift bounds can work fine with dithering, but won't work with changing the interpolation space.
<fantasai> lea: Wrt pixel-perfect, I've never seen pixel-perfect gradients used
<fantasai> lea: designiners who want that insert color stops to ensure the interpolation curve
<astearns> ack jensimmons
<lea> s/Wrt pixel-perfect, I've never seen pixel-perfect gradients used/I've never seen gradients that expect pixel perfect rendering really use sRGB. Even before in oklab was an option, they'd insert intermediate color stops to control interpolation, so the difference would be minimal./
<fantasai> jensimmons: I was surprised to hear that we decided to change default color space for gradients
<fantasai> jensimmons: surely there are designers and developers who don't care that much
<florian> q?
<TabAtkins> WPT, for example, lets you specify that pixels can be within an RGB unit or two of the reference.
<fantasai> jensimmons: also user gets new device, renders differently, or uses new browser
<fantasai> jensimmons: but certainly many designers obsess over the details and spent hours choosing the gradient ...
<fantasai> jensimmons: seems like CSSWG typically doesn't change out from how web works
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to say we have some wpt bugs because of dithering (which is allowed) but test reference assumes no dithering
<fantasai> jensimmons: so was surprised about resolution. Don't know if it's a good idea or not.
<fantasai> astearns: we resolved on this because it seemed like an improvement that could be ok with web-compat
<fantasai> astearns: but new behavior is fully accessible as an opt-in, right?
<fantasai> astearns: so we should probably resolve to revert this decision
<smfr> I tested Keynote on the web. It happens to use SVG, so it has an SVG gradient, but with just 3 stops. If it had used CSS this would have affected behavior
<florian> q+
<astearns> ack fantasai
<kbabbitt> fantasai: I don't quite remember but is there a way for author to opt in whole page at once?
<kbabbitt> ChrisL: has to be each individual gradient
<kbabbitt> ChrisL: people keep suggesting it but folks say that wouldn't work because..
<kbabbitt> fantasai: that means we don't have a proper opt-in
<kbabbitt> ... requiring authors to do it for every gradient seems obnoxious
<lea> q+ what ChrisL is not a showstopper, just an additional complication in the design
<kbabbitt> ... the improvement that's available is unlikely to be worth that level of effort
<lea> q+
<florian> q- later
<kbabbitt> ChrisL: the gradients they can opt in are ... the ones that work how they want, they don't have to do anything with
<dbaron> q+ to comment on global opt in versus global behavior change
<kbabbitt> fantasai: if we think this is an improvement for all gradients, we should make it easy for authors to opt in
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<ChrisL> I hope we can make this first issue next week, as we are close to resolution
<astearns> ack lea
<fantasai> lea: We can still have a global setting. Having different interpolation spaces for different use cases is possible, just not a single property with a single value
<astearns> ack florian
<fantasai> florian: don't have statistics, but the point made by lea makes sense to me
<fantasai> florian: ppl who obsess over their gradients would use intermediary color stops, and would therefore be minimally affected by this
<fantasai> florian: on the other hand, argument from smfr about having things on and off the web look the same in both cases ...
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on global opt in versus global behavior change
<smfr> I just disproved that apps add lots of color stops to control the rendering
<fantasai> dbaron: wrt global opt-in, if we thought global behavior change was good, then having global opt-in would make sense
<fantasai> ChrisL: global being problem was about all types of interpolation
<lea> e.g. color-interpolation-gradient
<florian> +1 to dbaron
<fantasai> lea, dbaron: we could have a global opt in that only affects gradients
<fantasai> astearns: should we resolve to revert?
<fantasai> ChrisL: I'd like to discuss an additional point next week
<fantasai> astearns: ok, let's do that and then continue with this discussion
<fantasai> astearns: proposed that we revert the change that says that gradients interpolate in OKL by default. Any objections?
<fantasai> RESOLVED: Revert change to make all gradients interpolate in OKL by default
svgeesus commentedon Jun 4, 2025
Spec updated
svgeesus commentedon Jun 5, 2025
The spec is updated: 12. Color Interpolation, the WPT and the spec text are in alignment, and the WPT results are pretty good.