I’m a little disappointed that there are no such options. The first thing I hoped for when I heard “variables” was just such parameterization. It would have made the management of variable styles much easier.
Yeap… tokens is a part of variables that is not complete yet.
We are waiting a speed deployment of all call to variables because we need them for opacities, gradients, shadows… I can’t really start working for my clients
bBETA] are cool but lUSERS] always want more
+1 ✋
This is what exactly I am trying to find in the variables. @bart13 Thanks for sharing your idea. This is really super important for the design systems.
There should be an additional option to set the opacity to that alias variables.
Dear Figma, I absolutely love what you’re doing with Dev Mode, Local Variables and I honestly cannot stop being amazed by the things coming out as of late. Please please please, if there’s one thing that would magically transform our dev workflow is to support either HEXA or RGBA or some way to incorporate the alpha channel as part of the the color definition when we define a color variable.
We do a lot of mobile development and it would make life so much easier if the transparency/alpha values came with the colors in the palette vs. having to define them and keep track of them elsewhere.
Purty please with sugar on top! Thanks heaps!
Want to support this request. We at Semrush need the support of alpha / opacity in the variables, too.
I have kind of a workarround - its not the its not the best - but it works (with paid token studio version)
you manage your tokens via token studio
Then you export the tokens via token studio to variables (do not start to edit tokens in variables! - management is done in token studio)
Now everything which is linked - remains linked in variables but as soon as its a RGBA value - its not a linked value in variables anymore but its a hex with opacity. This is completly fine since you manage your tokens in token studio and the logic of assining tokens happens there. You only assign the variables on Figma layers to get the best designer experience when changing themes
It might help you moving forward for now - but this is still a desired feature.
Yeah, thanks for the detailed workaround. In Semrush we use exactly the same workaround 🤓 Hoping some time in the future Figma will upgrade its native tokens so we would not need such workarounds at all.
Just started to work with variables and I cant stop wondering what stopped Figma from implementing this from the beginning.
+1 for wanting to be able to manipulate alpha transparency independently on aliased color variables.
My immediate use case is for establishing state variants for various semantic application colors (e.g., disabled items are transparent) that still reference our core color primitives.
The goal is to be able to set transparency at the semantic color definition level (rather than manually at the layer level) without having to either unlink each color from its respective primitive or, alternatively, maintaining entirely separate primitive color scales for each potential transparency level of ever single color within our primitives collection.
+1 !!! I dont understand why this feature wasn’t implemented in the last update !
+1. Please make variables usable.
+1. Please take variables to it’s true potential!
Im replying so the thread doesnt close, but I want this too. Very badly.
Growing a design system at our company and missing this feature badly right now as we do not want to use workarounds or third party plugins for maintaining variables.
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.
I use components to have all kinds of colour adjustments →
Medium – 23 Feb 24
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.
