When interpolating a color whose hue is undefined with a color with a defined hue, it works well for the undefined hue to be considered equal to the defined one.

A lab(L 0 0) color (equivalent to the deprecated gray() syntax) will produce lch(L 0 0). When a color authored in a different color space is converted to lch() and its chroma ends up 0, it's fair to consider its hue undefined, to enable the behavior above. However, when authored in lch() directly, a color with zero chroma (e.g. lch(50 0 0)) I guess we should honor the explicit hue?

Hmm, I haven't fully fleshed out the idea, but could we do a chroma premultiplication (for lch()) or saturation premultiplication (for hsl()) similar to an alpha premultiplication? That would make colors with a small chroma component conntribute less of their hue to the interpolation and might satisfy @tabatkins's math requirements? (Edit: on a more attentive read, @tabatkins actually suggests this approach. 🤦‍♂️)

I'll try a demo to see if it pans out.

I've made an interactive notebook to try it out. It works surprisingly well! It handles graciously and continuously zero, and near-zero, chroma:

But it's arguably not the "correct" interpolation with noticeably large chroma:

But it's arguably not the "correct" interpolation with noticeably large chroma

That was my conclusion also. A smooth transition away from the NaN fixup works for the "almost zero chroma" case at the expense of making all the small to large chroma values result in non-perceptually-uniform hue ramps. An abrupt transition is awkward. Maybe a fast transition where the chroma is still in the "very tiny but not zero" range?

Currently, the spec says

If one of the angles has the value NaN, then for interpolation, NaN is replaced by the value of the other hue angle. If both angles have the value NaN, then for interpolation, NaN is replaced by the value 0 for both angles.

(we already have Achromatic colors converted to hue-ish spaces should treat hue as "missing", not NaN so don't focus on the specific NaN or missing)

This avoids the area of not-really-perceptually-uniform by making the cutoff between "has a defined hue" and "achromatic" very close to the achromatic axis, so we et well defined behavior in all cases.

Is that sufficient, or is more needed?

I think for the scope of css-color-4 that note is sufficient. (Since it appears the longer hue interpolation leaves identical angles untouched, I don't see any possible interactions between hue fixup and NaN hues).

In the context of css-images, I assume for gradients this adjustment is made on a piecewise basis. So the #888 in linear-gradient(red, #888, green) gets red's hue on the first segment and green's hue on the second, if the interpolation happens in a cylindrical polar space.

Thanks for the confirmation regarding css color 4.

Re-tagging to css images and leaving open, so we don't forget

@danburzo wrote:

In the context of css-images, I assume for gradients this adjustment is made on a piecewise basis.

Yes, and the spec now says so explicitly.

So the #888 in linear-gradient(red, #888, green) gets red's hue on the first segment and green's hue on the second, if the interpolation happens in a cylindrical polar space.

I have just added that exact example to CSS Images 4.