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
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 It would be great feature.
Agreed this functionality would be so beneficial!
Yes please! Alpha must be decoupled from color variable! For all the reasons listed above.
++ 1
We really need this!
+1 for flexibility and reduced # of semantic tokens
+1 to this, would use it every day
+1 Not sure why this wouldn’t be similar to how number variables are applied to font size/line height/corner radius/etc.
This is an issue I keep running into, especially for components I create that use auto-layout, which assimilates the container & border into the frame, thus removing the ability to apply specific opacity values to each of them individually.
Just ran into this issue as well 😟
What a terrible way to add color variables in shadows.
Hey All, thanks for the feedback!
We’ll pass this onto the team for future consideration.
+1 on that. We got an AI but separate alpha variables are still not in Figma for some reason.
