- Let users set a variable value in %. It is useful for line-height (also for border radius
) - Add typography related items to Number scoping
17 Likes
First of all I want to emphasize that I am very happy with the newly released typography variables! Hereâs just a couple of variable related improvements I think would help make working with them a bit easier.
1. Change column width in Variables overview: Currently itâs not possible to drag the columns to change the width, within the variables overview modal. This would be great to allow seeing full variable names as sometimes they are longer than the fixed width of the first column.
2. Scoping for typography variables: Now when I have a Number variable, I canât scope to to only show when determining typography related values like a line height or font size.
3. Moving a set of variables into a different collection: Iâve currently placed the different levels of variables into 3 collections for the different levels (1. Primitives, 2. Semantic, 3. Component). I want to move them into the same collection so I only have to set one mode per page to apply the right mode (Brand A, Brand B). Now I have to do this per collection (twice, in my case), even though the values are the same (Brand A, Brand B). Alternative could be somehow combining modes with the same name.
Curious if any of these are upcoming/on the radar.
7 Likes
I agree about the scoping it needs to be a fast follow.
+100 Was about to post the same feedback. It took me a bit to figure out that I needed to keep âShow allâŚâ checked in order to use my type vars at all.
1 Like
The lack of proper scoping for Typography variables is a HUGE oversight. I donât know how Variables can come out of beta with this feature lacking. Just doesnât make any sense.
Please add scoping for Typography variables!!!
Also, we need percentage-based line-height variables. 
6 Likes
Percentage based values ASAP. It would speed up the workflow, you could just set a couple of line height variables (eg. 100%, 120%, 150%, âŚ) and apply them to various font sizes. Right now if you have multiple font sizes you need a pixel based line-height value for each size 
4 Likes
100% agree on the scoping here. I cant get line height variable to show unless its set to all. Ideally as a quick fix if Figma could at least get numerics tied to at least a width or gap scope so they arenât showing up everywhere.
Reiterate though, this was a great release! Really appreciate the drive and approach on how to apply this down through modes to breakpoints, this shows some good thought and understanding the scenarios out there.
2 Likes
Same feedback! Glad I found this thread 
2 Likes
Oddly enough, there seems to be some kind of smart detection going on with line height variables solely based on the presence of the words âlineâ and/or âheightâ in the variable name. See screenshot showing line height variables âproperlyâ scoped.
7 Likes
Another issue with variable support in text styles is paragraph spacing. You can bind paragraph spacing to a variable, but you have to turn on âShow in all supported propertiesâ rather than just turning on âText contentâ for the variableâs scope. I generally want to set the paragraph spacing to the same variable as the font size, but I donât want to see those variables everywhere.
2 Likes
Agreed with all feedback here.
+1 to % line height and scoping support - kinda baffling these arenât included already.
Additional feedback:
Our design system relies on variable fonts - that immediately makes # values for Weight variables useless for us because we need to dictate weight, width, slant, etc.
Additionally, none of our default combinations of weight + width correlate to any of the presets that came with the font. E.g. These âunnamedâ styles shown in the picture.
So far I havenât figured out any kind of syntax for string variables to make these âunnamedâ weights work. If anyone has figured it out please share your solution!
3 Likes
Seems that for the free viewer account there is no way to see the value of the text variable. On the image below for the color there are variable name and variable value. For the font â name only.
1 Like
I am designing a mobile app to align with iOS and Android device accessibility settings that scale text to seven different sizes. Extending the variable mode limit to seven instead of four for the Organization plan would be very helpful in creating mockups to show how text scales for the different accessibility settings.
It shouldnât cost extra to design for accessibility.
2 Likes
i came here looking for this exact question
1 Like
Do you have any problems with performance when I bind a variable to a text style? When I delete, it takes me a few seconds to remove. Iâve tested with other objects (graphics, shapes, etc.), and there are no problems but text.
Then I remove all the text variables and improve the speed of deleting text properties.
Percentages: I canât second this enough! Being able to work in percentages is essential to modern web design and addressing this would close a major gap between design and dev.
Root Size: Itâs great that Dev Mode offers the ability to view in rem, but not all frameworks use a base of 16px. It would be so powerful to be able to pair variables with rems. Let us choose the root size and specify other sizes by rem! This would be so powerful and eliminate a ton of rework to scale all components due to a modified base.
3 Likes
what @Rae_Gibbs2 said!
So much of âmodern web designâ is working with relative numbers (rem, em, %) and not absolutes (px).
A couple UX suggestions:
- in the fon-size dropdown, make the variable âhexagonâ option be the first option. Itâs irritating to no end, having to scrolldown 300x a day the long list of default size options just to get to the option to use variables. Ends up being faster/easier to just type the size needed and not use a variable.
- after I selected a variable as a font-size (I clearly have opted to work within a set of vars), the font-size dropdown should only display my font-size variables (scoping) and have a âcustom sizeâ at the bottom of the list.
Gotta say, every release is a mixed bag. On one hand supper happy to be able to use font-sizes, but on the other, implementation is an alpha or so half-assed to the point that makes its more difficult to use the anticipated feature and then you just stop using the feature because its too much hassle. There, vented.
1 Like
+1 for supporting % values
+1 for being able to adjust the column widths in the Variables modal
+1 for being able to move existing variables to a different collection
Adding a couple pieces of my own feedback (for context, my team manages the Design System for our organization):
- Being able to add a code syntax for variables is so usefulâparticularly for colors, but it doesnât seem quite as smooth for typography variables yet. Also, my engineering team uses mixins for our type styles, so consuming developers shouldnât actually be referencing the individual properties or applying those manually. Ideally, in the dev mode inspect panel, weâd be able to override the individual typography properties & just show the mixin & utility class they should be consuming. So perhaps, in addition to being able to add a code syntax, being able to turn others off as wellâalong with adding something custom like a utility classâwould be useful?
1 Like
There is a constant battle I am facing where I want to use âLocal variablesâ, but Figma is kind of blocking me from making it useful without having to set âLocal stylesâ. Aside from line-height, as it is not possible to set a percentage value (please fix), everything else can be prepared in âLocal variablesâ, but afterwards, I am forced to create âLocal stylesâ to actually have a quick shortcut to apply and remember these settings, e.g. for h1, h2, body, and so on. I wish it would be possible not to set âLocal stylesâ but instead set these through the âLocal variablesâ somehow.
Iâm sure others feel the same way, in order to deliver better tokenisation options when handing over to development and such. Or am I alone in this?
1 Like