[css-color-5] What's the use case for color-mix() per-component adjusters?

[LeaVerou]

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

I've looked again at @una's original proposal in https://gist.github.com/una/edcfa0d3600e0b89b2ebf266bf549721 but I can't find it there either.

What is the use case for mixing two colors with different percentages for each component, like in this example?

color-mix(rgb(82.02% 30.21% 35.02%) rgb(5.64% 55.94% 85.31%) hue(75.23%) lightness(68.4%));

I had trouble wrapping my head around these examples, as they seem to basically be trying to do color adjustment and interpolation together in one, pre-computed step.

Every use case I have ever seen for a color mixing function in preprocessors involves interpolation of all components together. Any use case I can think of for separate interpolation percentage per component is basically contorting color-mix() to do something that color-adjust() or the relative color functions do better (e.g. creating lighter/darker/muted variants).

I may be missing something, but I would propose keeping color-mix() sweet and simple with only colors, percentage, and color space, and offloading color manipulation onto color-adjust()/relative color functions, at least for now.

But @una has worked more with design systems, so hopefully she had some use cases in mind for the extended syntax?

[una]

I believe these were included for completeness, but I completely agree with keeping color-mix() simple. color-mix() should be akin to mixing two paint colors -- the only real controls here are:

• color 1
• color 2
• amount of color 2 mixed into color 1 based on percentage of total paint

For web, we can include an optional color space keyword as well, though I think in most cases this would be emitted.

[LeaVerou]

I think it's important to keep the color space argument, and maybe a keyword for hue interpolation, as it can make a big difference (though given that shorter is the default, maybe we don't need that?)

[tabatkins]

We've got one example from the forced-color-adjust that we discussed on a previous call - taking the alpha from an arbitrary author-specified color and transferring it onto a system color. This can't be done with color-adjust().

Other possible use-cases seem like they'd be in a similar space - taking one color as reference, make other colors have the same chroma and/or lightness while preserving their hue. These can possibly be done with color-adjust(), tho, if it's instead a case of "set these colors to a particular chroma/lightness" rather than specifically matching a reference color, but I can def see potential cases for the reference-color case. For example, specifying a primary color for a button, then letting the site's accent colors adjust to similar c+l (and then using color-adjust() as well to make them a little lighter/darker/etc so they serve as accent colors.

[LeaVerou]

@tabatkins All these use cases are about taking one component of one color and other components from another color verbatim without any interpolation, so using color-mix() for this feels like a hack, not like something that follows the author's mental model.

Perhaps we need to bite the bullet and add functions to extract individual color components? Preprocessors do have those.

For example, specifying a primary color for a button, then letting the site's accent colors adjust to similar c+l

This is pretty much exactly the kind of use case the relative color syntax is for (which is separate from color-adjust()).

[tabatkins]

Yes, I suspect the reasonable use-cases are indeed about verbatim lifting a component and applying it to another, not interpolating between them per-se. Any interpolation cases are best handled by full-color interpolation, I would suspect.

This is pretty much exactly the kind of use case the relative color syntax is for (which is separate from color-adjust()).

I don't see how it does that, unless, as you say, we do add some way to extract a channel from a color. Then I suppose it's lch(from var(--primary) l c hue-channel(var(--theme-1)) / a)?

Is this better than color-mix(var(--primary), var(--theme-1) hue(100%))?

[Crissov]

@LeaVerou

Perhaps we need to bite the bullet and add functions to extract individual color components?

As outlined in #3187?

[LeaVerou]

FWIW, Tab's last post convinced me. I still think it's a hack to use color-mix() to combine components from multiple colors, but using the relative color syntax would also be a hack, so it's the best solution we have right now.

Ideally we need functions to extract color components, though then how do we namespace? Maybe we could get away with just alpha(), hue(), chroma() and lightness()? Which components are the actual use cases for?

@Crissov that's what I thought at first, but this syntax is good for doing math on a single color's components, not combining components from two colors.

[una]

I'm happy to keep color-mix simple and move individual adjustments to color-adjust. I do think that the use cases for mixing just a few specific channels of one color with another color are limited (and not possible in design software currently as far as I know).

[LeaVerou]

But color-adjust() is intended for adjustment of a single color, basically the same use cases as the relative color syntax. How would it combine channels from two colors?

[una]

I don't think the use-cases for mixing a specific color channel from one color with a different base color (i.e. just the lightness of blue with red) are that common or possible in other design software, so I think its okay to not enable this capability.

One could do a color-adjust() within color-mix() to create transformations simultaneously (i.e. lighten blue by 10% then mix with red). This would enable 1-line adjustments used with dynamic variables.

[LeaVerou]

@una That does not cover the use cases @tabatkins mentioned though. If we remove this functionality from color-mix(), then there's nothing enabling these use cases.

[svgeesus]

Closing since color-mix no longer has per-component adjusters