[css-images-4] Add color space parameter to all gradient functions

[LeaVerou]

We should add an in <colorspace> keyword to all gradient functions to customize the color space interpolation happens in. Probably also need to be able to provide color-space specific parameters, like hue-shorter for polar spaces too.

[svgeesus]

I agree, as already used on color-mix() and color-adjust(), in <colorspace> is the natural way to extend gradients from their current sRGB-only state.

And yes, for cylindrical polar color spaces like HSL, HWB and LCH, an optional keyword for the hue direction is needed. The default value would be the shorter hue arc.

[LeaVerou]

Editorial: We should define a <color-interpolation> production for this that everything else can refer to. We should not be duplicating this syntax all around CSS.
We should prefix the hue interpolation keyword with hue-, as it may not make sense out of context (even in color-mix() it's weird, e.g. it's non-obvious what shorter in color-mix(in lch shorter, lime, red) does.

[svgeesus]

We should prefix the hue interpolation keyword with hue-, as it may not make sense out of context (even in color-mix() it's weird, e.g. it's non-obvious what shorter in color-mix(in lch shorter, lime, red) does.

Maybe we should also add the hue- prefix right in CSS color 4, in that case.

[LeaVerou]

We should prefix the hue interpolation keyword with hue-, as it may not make sense out of context (even in color-mix() it's weird, e.g. it's non-obvious what shorter in color-mix(in lch shorter, lime, red) does.

Maybe we should also add the hue- prefix right in CSS color 4, in that case.

I don’t understand what you’re proposing. Add it where?

[tabatkins]

I think Chris is just agreeing with you that we should rename the hue-interpolation keywords generally to have a hue- prefix. ^_^

Anyway agree, the gradient grammars can easily handle having these added in.

It looks like the hue-interpolation keyword is placed after or between colors, not used as a general method over the entire interpolation, right? So we'd put it in the <color-stop-hint> productions and say that it's either invalid or just meaningless if you're not transitioning in a hue-ful color space, while the in <color-space> production goes in the prelude.

[LeaVerou]

Oh yeah, the production I was proposing should definitely go in Color, I didn't realize that was ambiguous.
Though it may need to be Color 4, as that's where interpolation is defined.

I think something like:

<color-interpolation> = in <color-space> [ <hue-interpolation> ]?
<hue-interpolation> = hue-shorter | hue-longer | hue-increasing | hue-decreasing | hue-specified

If we want that kind of granularity, we should add the entire <color-interpolation> syntax to <color-stop-hint>, not just a part of it. This way people can also customize the color space the transition happens in. Hence the production would become:

<linear-color-hint> = <length-percentage> || <color-interpolation>

Note that there should still be a <color-interpolation> param in the first argument of gradients, to cover the vastly more common case of wanting to specify an interpolation strategy for the entire gradient.

In fact, the more I think about, the more I think there should just be a gradient-wide argument, and if authors request more granularity, then we can add it to color hint.

It looks like the hue-interpolation keyword is placed after or between colors

I had not actually realized this, this is new edit. I …don't think this should be the case. This is an argument for the interpolation, not an argument for the color.

[weinig]

There is also some discussion of this in #5833.

[svgeesus]

This has now been done, see CSS Color 4: 13.1. Color space for interpolation which defines

<color-interpolation-method> = in [ <<ectangular-color-space> | <polar-color-space> <hue-interpolation-method>? ]

which is used in CSS Images 4:

3.1. Linear Gradients: the linear-gradient() notation
3.2. Radial Gradients: the radial-gradient() notation
3.3. Conic Gradients: the conic-gradient() notation