Actually I’ve found that you can create a primitive token using a Hex and opacity, and then simply referencing this from other tokens (as I would other colour primitives) does the job.
Just means you end up having to create loads of primitives that are untethered to the root variables though, bit of a nightmare.
Wouldn’t overcomplicate things honestly, just decouple opacity from variables — as in, let me set the opacity in the individual instance, as I would with any other colour. There are so many circumstances where it makes sense to use a slightly different alpha value depending on the context (e.g. brighter colours like greens and yellows needing lower alpha values) that attempting to systematise it seems like a fools errand.
“Just decoupling opacity from variables” would absolutely break other functionality for design system usage.
I know your intent is to suggest an easy to implement solution, but easy solution for a complex problem will only create more problems elsewhere.
If I (as a heavy user and design system maintainer) got the ability to separately apply opacity on top of a variable (needed sometimes), but lost the ability incorporate opacity into a variable (needed always), I would rather not have the ability to apply opacity separately.
A more complex solution that allows for both is the only way to add value without losing it.
Yeah, sorry, I was just suggesting a way around it for now. But agree support for opacity within variables is still needed for easier maintenance. It could easily become messy otherwise.
1 Like
I use components to have all kinds of colour adjustments →
It’s under the “Colour adjustments” section if you wondering.
Here are the source in Figma →
Works well for me. This way I can fade, shade and tint any colour I like, make gradients without adding colours to the main palette and have drop shadow with any colour, opacity and blend mode.
Don’t necessarily have to throw the baby out with the bathwater, could maintain the coupling between opacity and variables, use the specified opacity as a default, and have a “lock/unlock” functionality to allow for opacity changes to be made on top of the variable?
I still don’t think it’s practical to define opacities so rigidly because of the intrinsic differences between how colours are rendered on screens, for example if you’re making a set of statusTag components, each with a subtle coloured outline, the alpha values for each would need to be slightly different to maintain perceptual consistency, even if you account for the lightness values in your palette, the perceptual difference between colours is well documented.
On some level maybe it would be worth adding a variable type called “Opacity”? That way you could define a palette of opacities to be applied “on-top” of each of your variables when appropriate?
Practically speaking, this is what we do in our frontend components library, an ::after pseudoelement that overlays a translucent white element to produce a highlight effect, however as we’re growing and have a need to use these resource tokens elsewhere (e.g. making those hover colours available in Javascript, instances where pseudoelements aren’t feasible, etc.) it’s becoming more and more of a necessity to actually have all of the root colours available and tokenised. I’m more concerned with outlines and box-shadows (for focus states, subtle element highlights, etc.) in this instance though unfortunately — great idea though.
Thank you for sharing! Great idea! This workaround will definitely come in handy for small libraries.
However, in larger libraries, it might unfortunately increase the weight of the library and negatively impact its performance.
Yes Please! much needed feature
+1, very useful feature
Yes, please add this one!
Please add this! Really critical to variable inheritance, and would provide much better parity with how variables work in a dev environment.
This would be a great idea! Just give the option to decouple opacity from a colour variable in the fill!
I found myself with this problem specially when defining colored shadows based on existing color variables in my palette. It makes perfect sense that in case you change the primitive color variable, the shadow color get updated but keeping a separate value for the opacity. This…
We could even discuss about to also allow opacity variables, like this…
But for shadows I think it a must to, at least, separate the color from the opacity value, because we can consider that the opacity, in that case, is a property of the shadow itself and not of the color.
So, more thoughts, maybe, instead of complicate things in the color variables part, like proposed in this post, it would be enough to allow every where Figma allow to choose a color from a library just keep the opacity as a separate value, and then, even allow opacity variables.
For those colors defined with an opacity value in the “primitive palette” it could do the work to translate the value to the opacity to the opacity field, then, you can override the opacity value with an opacity variable if you want, or just over-apply the opacity.
1 Like