Why you shouldn’t use vertical trim in Figma (yet)

Figma has a rather obscure but incredible feature called vertical trim. It’s not old, but it’s not new either. Either way, you might’ve missed it. In this article, I’ll explain what the vertical trim setting does, why it’s so awesome, but also why you shouldn’t use it yet.

The problem with line height

Without being overly technical, consider that typographic characters sometimes have a little extra spacing (“leading”) above the cap height and below the alphabetic baseline, resulting in the line height being larger than the font height and therefore each line of text having more breathing room. In fact, the Web Content Accessibility Guidelines (WCAG 2.2) specifies that line heights should be at least 1.5 times the font size for readability reasons.

(Accessibility benefits everybody, by the way.)

Now imagine that the first line of text in a text box has top leading even though it doesn’t lead on from another line of text or that the last line of text has bottom leading even though it doesn’t lead to another line of text. Also imagine that the text box itself has some top or bottom spacing too (e.g., 50px) so that it’s separated from other elements. The problem is that the perceived spacing is actually 50px plus whatever the leading is, and this problem has plagued designers and developers for years:

For designers, this problem messes with the measurements provided by smart guides in Figma and other UI design tools. For developers, it means that they have to adjust their paddings, margins, gaps, and so on to account for all of this extra space.

So, how do we solve this? Because line heights clearly serve a great purpose. A good solution could be that we trim the extra space from the edges of text boxes. Well, that’s exactly what Figma’s vertical trim setting does. It’s a very useful feature, so let’s have a look at the benefit that it provides and why I recommend using it eventually.

What is vertical trim in Figma?

Figma’s vertical trim feature, when set to Standard, does nothing. However, when set (on a text layer) to Cap height to baseline, Figma trims the space from the top of the text box to the cap height of the first line of text (as you might expect, the cap height marks the top of capitalized letters).

Similarly, Figma also trims the space from the bottom of the text box to the baseline of the last line of text (the baseline marks the bottom of letters not including descenders, which are the parts of letters that extend downwards).

The setting lives in the Text section of the Design panel, but you’ll need to click on the Type settings icon (the …):

In the example below, vertical trim ensures that the 50px spacing between the two layers actually amounts to 50px when measured from the bottom of the top layer to the cap height of the text layer since the extra space/leading has been trimmed.

However, all other leadings remain, of course (as you can see):

The problem with vertical trim

Well, there’s nothing wrong with vertical trim…if you’re only using it for design.

However, if your design needs to be translated to code (which I’d wager is likely), then Figma’s smart guide measurements will be off. This is because the vertical trim setting translates to leading-trim in CSS, which doesn’t work in any web browser (at least not for now), and as far as I know, other platforms/code languages don’t support text box trimming either. All design-to-code tools will translate the spacings wrong too, so if you ask me, Figma has jumped the gun here with vertical trim.

So what now?

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

The state of text box trimming

First of all, leading-trim isn’t called leading-trim anymore, so Figma’s dev mode code output won’t work even once web browsers support text box trimming. Now it’s called text-box-trim, which makes more sense since it’s not actually the leading that’s being trimmed; and for consistency, maybe Figma should follow suit and call it “text box trim” instead of “vertical trim” (…or maybe I’m just being a bit neurotic now).

Anyway, name changes like this allude to eventual web browser support. It shows that a feature has been discussed in some way and is more than just a fleeting thought. You can use Can I Use to track web browser support for text-box-trim:

As you can see, text-box-trim works in Safari Technology Preview (an experimental version of Safari) and recent versions of Safari under a feature flag (meaning that the feature needs to be turned on). This doesn’t guarantee that other web browsers will follow suit or even that Safari will move forward with text box trimming; however, they likely will.

On that note, I think we should explore the full extent of text-box-trim and how we might utilize it in Figma (in the future of course) to create different outcomes that you might not have considered before.

The different types of text box trimming

Firstly, text-box-trim actually accepts three values: top, bottom, and both. Figma only supports both at the moment, meaning that it trims from the top and bottom of the text box, but in the future we’ll likely have the option to trim from the top or bottom only.

Okay, now this is where things start to heat up.

There’s another CSS property called text-box-edge (text box trimming doesn’t work without it) that specifies where the text box is trimmed to exactly. Figma only supports what they label as Cap height to baseline, which is supposed to translate to text-box-edge: cap alphabetic; in CSS (with cap referring to the top trim and alphabetic to the bottom trim). However, the code output only declares cap — another error on Figma’s part.

Putting Figma’s shoddy implementation aside, though, in the future we can expect Figma to support the other text-box-edge values, of which we’ll dive into now.

We’ve already had a look at cap height and baseline, so let’s have a look at the ex value (“x-height”) now. If the baseline marks the bottom of letters not including descenders, think of x-height as marking the top of letters minus ascenders, or even better, the top of x’s:

text-box-edge: ideographic-ink; trims the extra top and/or bottom space from ideographic glyphs such as Chinese characters. Although, Chinese is actually logographic since every character (or “logograph”) has an individual meaning, so similarly to leading-trim, ideographic-ink might wind up with a new name:

Choosing the right type of text box trim

Vertical center alignment

Consider text within a button, vertically centered and trimmed to the x-height and alphabetic baseline, since almost everything in-between is occupied space. I mean, why center the text vertically based on the cap height when there’s only one capital letter, right?

Except that in a really subtle way, it looks sort of odd, doesn’t it? As if it’s too high by just one or two pixels?:

Yes, although all but one of the characters are vertically aligned, it doesn’t look like it, so instead we need to create what’s called optical alignment. This is when something looks aligned but technically isn’t. Instead, trimming the text to the cap height and alphabetic baseline looks better, even if all of the lowercase characters aren’t even vertically aligned anymore.

This happens because the capital letter helps our brains to visualize the invisible bounds of the text box, of which we now expect to be centered vertically regardless of what’s inside it:

Ascenders, which can ascend a very small amount beyond the cap height by the way, have the same effect. However, the reason why we often trim text boxes to the alphabetic baseline and not the descenders is because descenders aren’t that common (tidfhjklb are the letters that have ascenders whereas only qypgj are the letters that have descenders). So cap height to baseline it is.

However, you’ll likely want to trim to the x-height and alphabetic baseline in rare scenarios where you’re not using capital letters at all. Otherwise, you’ll wind up in a similar scenario where there appears to be more space above the text:

Vertical top alignment

Now consider two columns with content in them. The left column starts with an image and the right column starts with some text:

This looks odd too, right? In this example, trimming to the x-height doesn’t feel right. This is because our brains recognize alignment, using it to understand the relationship between different things. Just like they recognize the center alignment in the button example, they also recognize the top alignment in this example, except that the two elements aren’t actually aligned properly, particularly at the two visible corners where our brain sees them connect. So instead, trimming the text box to the cap height feels more satisfying aesthetically:

Now, if only we could trim the left and right sides of text boxes too…:

A problem for another day, I think.

Key takeaways

The web is constantly evolving thanks to new features and web browsers (eventually) implementing them. In terms of markup and styling, development is becoming easier and easier, and one of the reasons why this is happening at such an accelerated rate is because UI design tools are becoming more synchronized with code.

In my humble and perhaps biased opinion as a designer who develops, designers who understand how their designs translate to code are more valuable since they’re able to sidestep various problems that result in development bottlenecks, which as you might imagine translate to project delays and wasted resources.

I believe the same thing about developers and accessibility, because there are things such as tab order and dictation that designers aren’t able to cover as UI design tools simply don’t have the features for them to do so.

In this case, opting to use vertical trim in the future (and opting out for now) drastically reduces development turnaround times because adjusting spacings to account for line heights is such a boring and time-consuming task. Keep a close eye on the web browser support.

LogRocket: Analytics that give you UX insights without the need for interviews

LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.

See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.