Yes, we need that please !
It will be easy if using manually and so helpful, I hope to apply this feature, its from my biggest needs
I applied this way but its so difficult and not helpful
Hi Guys,
@OG_Can I think i have use case also.
Progress bars: From Figma community to personal experiments building responsive progress bars are not greatā¦
What I do is:
Level 1: Get a Main Frame (Main Container) apply autolayout ā and fill with no padding so it adapts to the Page
Level 2: Add additional Container (Frame) with autolayout so if needed round corners of progress bar and apply other effects; autolayout ā paddding 8px
Level 3: Add 2 Frames: First with the % and the other with fill
So this works fine if I make variants based on predefined frames, but if needed to adapt to all screens Iām toast. So If in Level 3 if the left frame was X% of the Level 2 frame and the other in fill then it would ajust just fine.
I believe percentages for variables can be very useful for line heights. Setting only 2 or 3 variables, such as 100%, 120%, and 140%, will prevent the need to adjust the line height to a numerical value. Currently, if you want to cover all screen sizes, the font sizes might range from 12 to 20, requiring you to create at least 8 to 16 different line heights.
Yes please! and also for Letter spacing! It doesnāt make sense to have fixed numbers for Lineheight and Letter spacing. With that, in our system we would have to add a variable for each textstyle, whereas if you do it in percentages you would only need 2 or 3. For example: 115% lineheight for titles and 150% for body.
To have percentages in autolayout would also be great. Or maybe you can make this dependent on grid, so that you can specify a number of columns for example in a grid of 12 columns. You would als have to take the gaps between columns into account so that is a little more complex.
Kind of weird, because there are some cases where relative values (%) are possible like here (letter spacing):
And when appling a variable it only supports pixels:
Thatās bad and should be supported.
+1 Strongly needed. For instance, during development, I always use the ācalcā function for mobile sizing. For example:
@media screen and (max-width: 479px) {
html {
font-size: calc(0.75rem + 0.42vw);
}
}
This method is efficient and generally ensures that everything fits perfectly with minimal adjustments. The challenge, however, is keeping the mobile designs in Figma synchronized with the actual scaling used in the developed version. Therefore, utilizing relative size units would be optimal, especially when combined with ācalcā to mix different size units. Additionally, incorporating the frame width as āvwā should be quite feasible. It should also be possible to set a base font size in Figma for specific frame widths.
Please add
Please dear God, prioritize this. It would save SO much work.
Yeah thatās how it should actually work, but thatās not the way it works in Figma. Causes so much pain and violations of the DRY principle.
I donāt understand how this is still unsupported. Figma has built in percentage support for things like line height. Why in the world would they release variables without supporting percentages?
PLEASE for corner radius and stroke, too.
Another +1 here.
Tried to save line-height percentages as variables (i.e. "loose": "200%"
) and it seems they are unsupported, even as strings.
Upvote for variables using percentage. Would definitely use this feature.
Absolutely +1 for this feature
+1 also for the Topic and there are many more ideas around percentage: Fr/Percent units for more control over auto layout content
@atien +1 for this feature. Will also be especially useful for things like line-height and letter spacing. We use unitless values in CSS not fixed px values which could vary between fonts and modes.
Absolutely a good idea. Need it for line height and letter spacing.
I feel like this feature is almost a requirement to have considering modern webdev principles. Percents should also be applied to the Variables features. Currently there is only a āNumberā variable, which is just limited to floating point numbers, very limited application.
The only cases I can see that it may cause issues is for values that arenāt entirely tied to dimensions, but for line-height. This kind of case, should always be relative to the font-size (e.g. if Variable-A = 150% or 1.5x, and another variable Font-Size = 16, a third variable Header = Font-Size * Variable-A wold result in Header = 24)
This could also help with opacities in colors and pass through %.
Overall, the feature would help to streamline not just the concern for responsive design, but also unify other features as well.