Skip to main content

Variables: Color alias with alpha / opacity (rgba ideally)


Show first post

79 replies

ass
  • 4 replies
  • February 23, 2024

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?


ass
  • 4 replies
  • February 23, 2024

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.


Julia_Mnizhek

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.


Ivan_Manolov

Yes Please! much needed feature


Carina_Ostermayer

+1, very useful feature


  • 26 replies
  • April 3, 2024

Yes, please add this one!


Josh_Kriese
  • New Member
  • 2 replies
  • April 11, 2024

Please add this! Really critical to variable inheritance, and would provide much better parity with how variables work in a dev environment.


RickvandeSande

This would be a great idea! Just give the option to decouple opacity from a colour variable in the fill!


AntonioB
  • 5 replies
  • April 23, 2024

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…

image

We could even discuss about to also allow opacity variables, like this…

image

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!


Philip_Hodges

Yes please! Alpha must be decoupled from color variable! For all the reasons listed above.


FilipaGo
  • New Member
  • 15 replies
  • June 5, 2024

++ 1
We really need this!


Bob_Medcalf

+1 for flexibility and reduced # of semantic tokens


+1 Yes, please!


Jacob_Kersh

+1 to this, would use it every day


+1, would be so helpful!


Nathalie_Gouzee1

+1, please !


Jesse_Penico

+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.


Andy33
  • New Participant
  • 15 replies
  • July 8, 2024

bumping this


FilipaGo
  • New Member
  • 15 replies
  • July 10, 2024

Just ran into this issue as well 😟
What a terrible way to add color variables in shadows.


djv
Figmate
  • Community Support
  • 4798 replies
  • July 10, 2024

Hey All, thanks for the feedback!

We’ll pass this onto the team for future consideration.


Oleh_Shydlovskyi

+1 on that. We got an AI but separate alpha variables are still not in Figma for some reason.


yes please. much needed.


Badly needed. thanks


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings