[css-color-4] Do gradients/animations using lab/lch colors interpolate in the Lab colorspace?

[smfr]

When gradients and animations use lab()/lch() colors, should the gradient/animation interpolate in the lab() colorspace?

If a gradient/animation uses a mixture of lab() and rgb() colors, I assume it would fall back to RGB interpolation.

What happens if you mix lab() and colors in one of the other predefined colorspaces (display-p3, rec-2020 etc)?

[smfr]

@svgeesus

[Crissov]

Isnʼt this just #300 reloaded?

Unless the author or user requested something else, the browser would be expected to use sRGB as its working color space for webcompat.

[smfr]

I don't think so. Authors will be using lab()/lch() for their consistent treatment of lightness, so a gradient from lch(50% 100 10deg) to lch(50% 100 100deg) should use lightness 50% for all its colors. You won't get that if colors are interpolate in sRGB, and I don't think authors should have to opt the entire page into a working lab colorspace to get this.

[svgeesus]

When gradients and animations use lab()/lch() colors, should the gradient/animation interpolate in the lab() colorspace?

Ideally, yes. But they won't by default, because then the second half of a gradient from

1. some Lab color
2. an sRGB color
3. another sRGB color

would be different in implementations that support lab() and lch(). So for webcompat, the default needs to be sRGB as at present.

Isnʼt this just #300 reloaded?

Yes.

I don't think authors should have to opt the entire page into a working lab colorspace to get this.

I agree, which is why a per-element working colorspace, rather than a brute force all-or-nothing working colorspace for the whole page, is more flexible and author friendly.

[LeaVerou]

I think we all agree that Lab interpolation is in every way superior, and the only reason we can't switch everything to that by default is backwards compat, right?

Assuming the above statement is correct, I think anything where authors have to explicitly enable lab interpolation is a bad idea from a usability point of view and should be a last resort if nothing more reasonable can be implemented. It seems reasonable to me that as long as there's at least 1 non-sRGB color, the interpolation should happen in Lab, since there's no backwards compat concern.

If a gradient/animation uses a mixture of lab() and rgb() colors, I assume it would fall back to RGB interpolation.

If you interpolate Lab and sRGB via sRGB interpolation, you could end up having an abrupt jump in the first interpolation step, since the Lab color may be outside the sRGB gamut. Given that sRGB is rather small compared to Lab, that's not a rare case, but significantly more than 50% likely. Interpolation must always happen in a superset of the gamuts of the colors involved, so Lab is a safe choice, whereas sRGB is not.

What happens if you mix lab() and colors in one of the other predefined colorspaces (display-p3, rec-2020 etc)?

Given that Lab encompasses all visible colors, Lab interpolation should be safe here too.

[LeaVerou]

I agree, which is why a per-element working colorspace, rather than a brute force all-or-nothing working colorspace for the whole page, is more flexible and author friendly.

I don't think per-element would cut it either, ideally it needs to be per operation.
You could have a transition and a gradient on the same element, from different stylesheets. One of them is between sRGB colors, the other between Lab colors. You need to interpolate the former in sRGB for webcompat, but the latter in Lab because sRGB would produce terrible results (since the colors could very likely be both out of sRGB gamut).
There could be a document or element color space to fall back on perhaps, but interpolating Lab colors in sRGB should never happen.

[faceless2]

It seems reasonable to me that as long as there's at least 1 non-sRGB color, the interpolation should happen in Lab, since there's no backwards compat concern.

I think this is definitely moving in the right direction, but would suggest modifying this so that if the gradient contains multiple colorspaces, interpolation should happen in an appropriate space that is a superset of them all.

• A gradient from device-cmyk to device-cmyk should remain in that space.
• A gradient from sRGB to a wide-gamut RGB should probably occur in the wide gamut RGB for best results
• A gradient from Lab to Lch, or Lab to Lab should be done in Lab
• A gradient from device-cmyk to sRGB, or sRGB to Lab, or some other exotic combination is fairly unikely to give good results, and I'd expect would be down to the user not understanding what they've asked for. I would think the least-bad option is to choose a color space that has a wide enough gamut, which will effectively be Lab.

Edit:

I think we all agree that Lab interpolation is in every way superior, and the only reason we can't switch everything to that by default is backwards compat, right?

Actually while testing for #2023 I found this not always to be the case. Gradients between two Pantone colors based on the Lab space didn't look as "correct" to me as a gradient between them in the CMYK space. Subjective, yes, but I don't think we can assume Lab will always be the best choice. I can knock up an example if this would be useful.

[LeaVerou]

How about the following heuristic then:

• Interpolation between colors of the same color space is done in that color space
• Interpolation between colors of different color spaces, where one color space is a strict subset of the other is done in the wider color space
• Any other interpolation is done in Lab

The heuristic can easily be overridden to a wider color space with the relative color syntax from #3187 that is added in Color 5.

A gradient from device-cmyk to sRGB, or sRGB to Lab, or some other exotic combination is fairly unikely to give good results, and I'd expect would be down to the user not understanding what they've asked for.

Not necessarily. It could be between a variable/user defined color and a fixed color. I don't think we should brush off such use cases.

[svgeesus]

Given that Lab encompasses all visible colors, Lab interpolation should be safe here too.

Yes.

I don't think per-element would cut it either, ideally it needs to be per operation.
You could have a transition and a gradient on the same element, from different stylesheets. One of them is between sRGB colors, the other between Lab colors. You need to interpolate the former in sRGB for webcompat, but the latter in Lab because sRGB would produce terrible results (since the colors could very likely be both out of sRGB gamut).

Ouch, you are right. (This is why SVG had separate color-interpolation and color-interpolation-filters properties, with different initial values).

[svgeesus]

Interpolation between colors of different color spaces, where one color space is a strict subset of the other is done in the wider color space

Do we particularly need that one? "wider" is not easily determined; for example display-p3 and a98-rgb are largely overlapping; though prophoto-rgb is wider (and includes imaginary colors)

[LeaVerou]

Do we particularly need that one? "wider" is not easily determined; for example display-p3 and a98-rgb are largely overlapping; though prophoto-rgb is wider (and includes imaginary colors)

I was wondering about that. I think 1 and 3 are sufficient, especially if there's a way to override the heuristic (e.g. relative color syntax to convert between color spaces)

[faceless2]

Having a requirement to blend in Lab when you know you can get better, and faster results in another space better seems counter-productive. It might be useful to leave this door open for implementers, but I'm not very invested in this position so long as point 1 remains.

[svgeesus]

blend in Lab when you know you can get better, and faster results in another space

Could you give an example where blending in another space than Lab is better? I can only think of blending in LCH.

Also, the proposal is not to force blending in Lab, just to have that as a sensible default. Overriding to explicitly use another space would still be allowed. The point is to not require such an override every single time (to avoid blending in sRGB).