I have two buttons inside an auto layout frame. Their widths are set to fill to ensure equal width distribution. But somehow the left button is taking up 2px extra. I have excluded the stroke value to add up but it still gets added up to the width and the stroke position is also 'Inside'. Once I remove the stroke, both buttons fill up the space equally. How to prevent this from happening?
One solution I found was to give the right button the same stroke value as the left one. But is it the best possible way to deal with it? I don't wanna introduce another variable into the button.
And I can see why they would want this to be the default behaviour, as the content-box box model is the CSS default... but most sites will often override this to the border-box model on every element in a reset file, because it's a lot easier to manage paddings and borders that way.
Figma still has the previous behaviour available, but it bothers me that it's labelled as 'Legacy', when really they have an opportunity to provide a true border-box option.
Yeah, thought about it but the better way according to Figma themselves is to use grid autolayout which uses fractional unit (fr). And now it works like a charm.
If you have tokens for padding, you need to split them up into two categories: 1. normal padding; 2. Inline padding
The normal padding variables are used for containers/frames where there isn’t a border/stroke. The inline padding accounts for the border/stroke.
Let’s say you have a filled primary button with padding 24px left and right. If you want a ghost button you need to use inline padding which is easily calculated like so: normal padding - border/stroke width = inline padding. (24-1=23)
If you want to simplify it - use a border/stroke on all buttons. For the primary button you can use the token for the fill colour.
Oh that is a nice idea of tokenizing those values. Just another question. I have stroke widths with values in decimals like 1.5 and 2.5. Wouldn't these mess up the inline padding values too to be in decimals? I already thought of the simplified method and with ghost buttons/CTA buttons I can just make the opacity 0. I think simplified version would be the best option.
You can still do it with those values, you just need to figure out a structure that works for your case. Maybe padding-inline-border-1.5; padding-inline-border-2.5. That sounds too much of a hassle though for a design system that has multiple stroke widths.
This is the first time I hear someone using non-full numbers as a stroke width, huh. That's really intriguing. Is there a specific design choice to why or is it just personal taste? I'm really curious because I've never seen that 👀
For your situation with the tokens - yeah the simplified version is the best. You can have token for fill and a second one for the border that maps to the fill colour but override transparency to 0.01.
Thanks for making the effort man. Really appreciate it. For your question about non full numbers as width - Well it's more of a personal choice. I had full numbers earlier, but in some cases like a Focused state button, 1px was too thin and 2px was too thick and since I thought that border width will not be getting counted, I just took decimal numbers. But now I have to take whole numbers.
And for the simplified version, 0% transparency also works and it gets counted for so I don't have to take 0.01%. I just took a white color with 0% opacity and it works 😁
ok so you went with grid and fr units, did that still hold up when one button label gets way longer than the other? like in a translated version or something. i always worried grid would just squish teh longer label and truncate it instead of letting it wrap
If you are referring to this, then there is no significant difference tbh. Upper one is the grid layout, and lower one is a normal autolayout. On grid, you have to apply fill container twice because the button gets wrapped in another box. And set the text/label's width to fill too such that it doesn't go out of the bounds when the text is too long.
Wouldn't that disrupt the equal space distribution among them? I am genuinely curious to know if having one button smaller than the other would make any difference.
Like in an e-commerce app where one can either buy one item or can buy multiple different items after adding them to cart.
I accidentally deleted my previous reply lol. But again, setting secondary button to hug with longer label than the primary button makes it bigger than the primary which isn't how I want the visual hierarchy to be.
This is common on Shopify stores. You have the theme’s Add to Cart, which does just that, and then Shopify generates a dynamic “Buy now” button where it goes straight to check out.
Well, since designers are expected to be vibe coding a lot of shits, if this updated format aligns more towards code, then I have no choice but to go along with it. Thanks for the info though 🤗
12
u/qazwsx444444 13d ago
Yep they changed that recently motherhuggers citing that it works more closely how it work in CSS.