See my response to your bending colorspace question

Re-tagging to CSS Images 4, where gradients are defined.

As defined in CSS Color 4, unless the host syntax overrides (and currently there is no gradient syntax to override) then pairs of legacy sRGB colors will interpolate in gamma-encoded sRGB. This is necessary for Web compat.

A pair of non-legacy colors, ore one legacy and one non-legacy, will interpolate in Lab. This includes the non-legacy color(srgb) form.

CSS Images 4 should define a host override syntax to allow other choices of interpolation colorspace.

It would be nice if CSS images would also provide a way to automatically deduce a colorspace, so it doesn't default to Lab for any non-legacy colors.

In particular when all colors of the gradient are defined in the same colorspace, it should use that colorspace.

In particular when all colors of the gradient are defined in the same colorspace, it should use that colorspace.

That would be one option, but you don't say why it is a good idea (and for many colorspaces it would not be a good idea). It also introduces fragility and surprise: add one color stop and suddenly all the rest of your gradient mysteriously changes.

The main reason why I consider it a good idea is when the whole CSS file is using the same colorspace for all colors - I could imagine that for CMYK as well as when targeting hardware-specific CSS, like for TVs or cars. Having to add "in @myspace" to every gradient feels tedious and is also easy to forget.

And the fragility and surprise is already a problem I guess, when something like linear-gradient(white, var(--user-color), black) can either be sRGB to Lab, depending on the variable.
You are right though that the more advanced the magic to deduce the colorspace, the more fragile it becomes.

I don't have a good solution either, I'd just like a way to avoid lots of "in @myspace".

Note that color interpolation syntax was just added to all gradient functions in 1f940c6

In particular when all colors of the gradient are defined in the same colorspace, it should use that colorspace.

We have explored using this as a heuristic, but it's a poor heuristic for any gamma-encoded RGB space (e.g. you wouldn't want two display-p3 colors to interpolate in that space).

There might be value in providing the ability to set defaults for color interpolation, but that wouldn't be gradient specific.

What is the expectation when the color stops are in different color spaces? What happens if single gradient has color values in different color spaces?

This is now well-defined in the specifications: see 3.5.2. Coloring the Gradient Line

Please forgive me to comment on this closed issue. It is not clear to me what the color interpolation method is when it is not specified in the gradient input argument.

When omitted, my understanding is that color stops interpolate in oklab, even if some colors are specified in different color spaces. Assuming oklab is the default method, I would like to know if in oklab should be omitted (according to the shortest serialization principle) when serializing linear-gradient(in oklab, red, color(display-p3 0 100% 100%)).

I guess that gradient colors defined in different color spaces are otherwise gamut mapped in the color interpolation method specified for the gradient.

3.5.2. Coloring the Gradient Line:

If no <color-interpolation-method> is specified in the gradient function, the color space used for gradient interpolation is the default interpolation color space as defined in [css-color-4].

12.1. Color Space for Interpolation:

The host syntax should define what the default interpolation color space should be for each case, and optionally provide syntax for authors to override this default. If such syntax is part of a property value, it should use a <color-interpolation-method> token

If the host syntax does not define what color space interpolation should take place in, it defaults to Oklab.

but

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.

That may means that for gradients with no <color-interpolation-method> where all the stops are in legacy sRGB, the spec is intentionally vague on what color space is used for interpolation (thus permitting existing legacy behavior). It is allowed to be Oklab and it is allowed to be sRGB.

So (to answer a question you didn't ask) in this case I feel that serialization should include an explicit <color-interpolation-method>. Currently the spec doesn't say that, because there is disagreement on the level of backwards compatibility we really need.

To answer the question you did ask (explicit in oklab, at least one non-legacy-sRGB stop) shortest serialization would indeed suggest omitting the in oklab but I am not sure that is wise.

The serialization section of CSS Images 4 is brief and somewhat vague and should probably be examined more carefully and given several more examples. I see small changes compared to serialization in CSS Images 3 and neither level of that spec clearly states whether specified or computed values are being serialized. Notice how the example changes between the two. The impact of <color-interpolation-method> on serialization is completely unspecified, so thanks for drawing attention to that!.

@fantasai @LeaVerou

for gradients with no <color-interpolation-method> where all the stops are in legacy sRGB, the spec is intentionally vague on what color space is used for interpolation

This differs with your previous comment above:

pairs of legacy sRGB colors will interpolate in gamma-encoded sRGB

I guess it might makes sense to require all color stops to be legacy sRGB. For example, the last two color stops in red, green, color(srgb 0 0 100%) would interpolate in oklab, right?

There is currently no <color-interpolation-method> value matching this behavior though.

there is disagreement on the level of backwards compatibility we really need

You may be referring to #7948.

I will wait for your next edits on this. Thanks for your hindsightful reply (as usual).

Aside: I recently commented on some problematic/missing requirements for gradient serialization.

This differs with your #6094 (comment):

The spec also differs, between now and the time I wrote that comment :)

You may be referring to #7948.

Yes.