-
Notifications
You must be signed in to change notification settings - Fork 719
[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
Comments
I believe these were included for completeness, but I completely agree with keeping
For web, we can include an optional color space keyword as well, though I think in most cases this would be emitted. |
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 |
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 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 |
@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 Perhaps we need to bite the bullet and add functions to extract individual color components? Preprocessors do have those.
This is pretty much exactly the kind of use case the relative color syntax is for (which is separate from |
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.
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 Is this better than |
FWIW, Tab's last post convinced me. I still think it's a hack to use Ideally we need functions to extract color components, though then how do we namespace? Maybe we could get away with just @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. |
I'm happy to keep |
But |
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 |
@una That does not cover the use cases @tabatkins mentioned though. If we remove this functionality from |
Closing since |
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?
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 thatcolor-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 ontocolor-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?
The text was updated successfully, but these errors were encountered: