Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LeaVerou opened this issue Jun 11, 2020 · 12 comments
Closed
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-color-5 Color modification

Comments

@LeaVerou
Copy link
Member

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?

@LeaVerou LeaVerou added the css-color-5 Color modification label Jun 11, 2020
@una
Copy link
Contributor

una commented Jun 11, 2020

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Contributor

Crissov commented Jun 12, 2020

@LeaVerou

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

As outlined in #3187?

@LeaVerou
Copy link
Member Author

LeaVerou commented Jul 2, 2020

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
Copy link
Contributor

una commented Jul 2, 2020

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
Copy link
Member Author

LeaVerou commented Jul 3, 2020

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
Copy link
Contributor

una commented Jul 6, 2020

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
Copy link
Member Author

LeaVerou commented Jul 7, 2020

@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
Copy link
Contributor

svgeesus commented Dec 1, 2021

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

@svgeesus svgeesus closed this as completed Dec 1, 2021
@svgeesus svgeesus added the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Dec 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-color-5 Color modification
Projects
None yet
Development

No branches or pull requests

5 participants