[css-color-5] When mixing hue, there are two ways round the hue range

[smfr]

https://drafts.csswg.org/css-color-5/#colormix

Mixing hue in lch() leads to ambiguity (or undesirable results) because hue is an angle around the circle, so there are two paths between any two values. In some cases, authors may want a hue mix that traverses the 0deg/360deg point, at other times not.

[svgeesus]

I have been wondering about that myself. Maybe an extra parameter with two values, to go 'the long way round' or 'the short way round' with shorter path being the default if unspecified? It would also need tie logic, so that both paths are available when the path is exactly 180deg.

[jrus]

Unless explicitly specified, this should always be the shortest arc.

[tabatkins]

Once the spec is fixed to not mod the angle eagerly, the consistent answer is to just do a linear interpolation from the start to the end angle. If you want a particular direction, you can specify the angles to cause that direction, just like you do with 'rotate'.

[jrus]

the consistent answer is to just do a linear interpolation from the start to the end angle

The big problem is that many authors are going to want to set gradient stops or color mix endpoints either (a) from coordinates provided by a graphical tool, (b) in a different coordinate system [mixing in polar-coordinate CIELAB (L*, C*, h*) space is apparently the default irrespective of the space in which a color is specified], or (c) from a specific named color not specified adjacent to the usage in a gradient/color mix.

When this happens for e.g. a red and a purple, the gradient should go the short way through red–purple, but from what I can tell according to this proposal will instead go all the way around via orange→yellow→green→blue.

This is going to be very confusing for authors, and difficult or even impossible for them to fix in a straightforward way.

---

For creators of graphical tools for creating gradients or color mixtures, outputting to css, this is going to create some sticky edge cases which are difficult to work around. The hue angle specified for each color will need to be adjusted by an arbitrary multiple of 360° based on the specified angle of the previous color.

If trying to make a collection of color mixes between several different colors, each original color may need to be specified multiple times for different numbers of turns around the circle, so that mixtures with others end up behaving as expected.

[faceless2]

You've mentioned authors using "a graphical tool" consistently in your case for using the shortest path between the angles. Presumably this tool could also convert a gradient from 340° to 20° into -20° to 20° in the generated CSS.

[jrus]

There are 2 cases: (1) an author uses a graphical tool to obtain coordinates, and then copy/pastes those coordinates into a document. That puts the burden of figuring out what multiple of 360° to get the desired behavior onto the end user; (2) the graphical tool generates a whole gradient or color mix or whatever, and outputs CSS. In that case you are complicating the tool programmer’s job and making it more likely that their tools will have undesired behavior.

For e.g. a gradient, the tool is going to need to keep track of the turning number of every gradient stop, and potentially change every one in response to any change to the gradient. What would previously be a local update to 1 value becomes a fiddly global update.

[svgeesus]

@tab wrote:

Once the spec is fixed to not mod the angle eagerly, the consistent answer is to just do a linear interpolation from the start to the end angle. If you want a particular direction, you can specify the angles to cause that direction, just like you do with 'rotate'

Suppose I have

--start: lch(52% 58.1 22.7) 
--end: lch(56% 49.1 257.1)

// currently, this goes the long way around
color-mix(var(--start) var(--end) hue(75.23%));

//  22.7 * 0.7523 + 257.1 * 0.2477 = 80.76
// mixed result is lch(52% 58.1 80.76)

You seem to be saying that going the other way round I would need to inspect the values of the two custom properties and if needed, add or subtract 360 to make it do what I want.

--otherend: lch(56% 49.1 -102.9)

// now it goes the short way around
color-mix(var(--start) var(--otherend) hue(75.23%));

// 22.7 * 0.7523 + -102.9 * ( 1 - 0.7523 ) = -8.41112
// mixed result is lch(52% 58.1 -8.41112)

while what I am suggesting does not require making adjusted copies of custom properties:

// this would go the short way around
color-mix(var(--start) var(--end) hue(75.23% short));
// this would go the long way around
color-mix(var(--start) var(--end) hue(75.23% long));
// new default if unspecified, go the short way around
color-mix(var(--start) var(--end) hue(75.23%));

[svgeesus]

Also, doing calculations in LCH does not mean that the colors being mixed were originally specified in LCH. So tweaking the angle by adding or subtracting 360 is not even an option in those cases.

Consider mixing a hex color (thus, sRGB) with a color in prophoto-rgb:

color-mix(#123456 color(prophoto-rgb 0.9137 0.5882 0.4784));

The two input colors are auto-converted to LCH and then mixed. Relying on the user tweaking hue angle implies always requiring the user to first convert the colors to LCH.

[tabatkins]

Yeah, there's tradeoffs.

Just doing a linear interpolation is simpler and more consistent with how all other values in CSS transition, and gives authors that are hand-authoring the values simple, straightforward control over how their transition proceeds. It does mean that authors doing generic work on custom property values don't have insight into how it'll work (tho the users of the component in question can always hand-tweak their values to get the desired result), and yes, when your endpoints aren't in a cylindrical space you don't have any control.

Doing a "shortest-path" interpolation is a break from that: it might be more commonly what's desired, but it means we have to make an arbitrary decision for 180deg separation, and we have to add further controls to let the author opt into the other modes when that's desired (at least four settings, as {longest path, shortest path}×{CW when 180deg, CCW when 180deg} are all possible).

[faceless2]

After reading Chris's posts, I'm going to change my opinion. Under any other circumstances I'm very strongly for normal linear interpolation like we do everywhere else, but for color-mix, I think you have to take the shortest route.

The critical difference is that colors are likely being mixed in a different space to the one they're specified - even if both colors are specified in the same space. So the user has no real control over the components being mixed.

I expect the vast, vast majority of people using this will be doing so in RGB, and most of them won't have even heard of Lch. If someone tries to mix from green to yellow and find it goes "the long way round", it's going to seem wrong and won't be obvious how to solve it.

One solution is to explain the Lch colorwheel and give them a flag to set; another is for them to specify both colors in Lch. Neither is good.

I think the principle of least surprise requires color-mix to interpolate in the shortest direction, certainly when either color is not specified in Lch. Myself, I think the 180° decision should be arbitrary and fixed (e.g. to clockwise).

If both colors are Lch to start with, you could go either way - shortest path for consistency, normal interpolation for full control. I lean towards the latter, as it means for most people in most colorspaces it will do the right thing, and those that really care about the details can specify their colors in Lch.

[svgeesus]

So I'm thinking of an optional second argument to the hue adjuster. Instead of

hue: 'hue(' <percent> ')'

it will be

hue: 'hue(' <percent> [shorter | longer | clockwise | anticlockwise]? ')'

with the default, if omitted, being 'shorter' and the direction, if the hue difference is exactly 180deg, being 'clockwise'. So you get what you want most of the time, and you can get exactly what you want by being specific.

[tabatkins]

shorter and longer still have the problem that they're ambiguous if the difference is 180deg; we'd either have to make an arbitrary choice or make the grammar [shorter | longer] || [clockwise | anticlockwise].

[svgeesus]

@tabatkins wrote:

shorter and longer still have the problem that they're ambiguous if the difference is 180deg;

which is why I wrote, earlier:

and the direction, if the hue difference is exactly 180deg, being 'clockwise'