I love the vertical trim option that just came out. But as of now it’s not supported by any browsers. So if you enable this feature the developer you hand off too will not be able to use vertical trimming, therefore your all the designs will be off due to the larger line heights that the vertical trim was subtracting.
So while this is a great idea, if you can’t actually use it on the web yet, you’re just making more work for yourself and your developer.
Am I missing something here?
When enabled it sets a certain line height, e.g. 12px font size results 9px line height which means you can set it with CSS
My understanding is that it doesn’t set or change the line height at all. It trims the top and bottom of the HTML element using a draft CSS property called ‘leading-trim’. But if you can’t use that setting, which is everyone at this point in time, then the developer will have to ask the designer to go in and turn off ‘vertical trimming’ and find out the proper spacing so that they can make it happen in browser.
I guess my point is that this feature is cool but useless because it only helps the designer by making padding / margins easier. But then when you hand it off the developer will have to reverse engineer all the spacing because they can’t use this draft CSS property yet.
Right??
Or they will measure the height of the text layer and use the same line height to get the same result. no guarantee that a dev guy is going to realize there is a special CSS prop to apply
But changing line height to make the vertical sizes the same isn’t the same result as trimming. If you lower the line height to compensate that makes the text closer together.
In trimming you’re removing whitespace only at the ends, but in adjusting line heights you’re removing whitespace for every line. So they’re not the same result.
I guess the reason I’m posting is because I’m trying to build out some stuff I’ve made in Figma using this feature. But after using it I’m realizing without the CSS draft being in any browser, it means I have to go back and turn off the feature on everything I used it on, and then figure out the correct padding to compensate and make it look like it should.
This is a huge pain if you weren’t expecting it, and it only makes the design stage easier but leaves the development with a ton of work they will very likely not notice. Which will end with all the fussed over UI spacing wrong in the final product.
Here is an image outlining the issue:
Hi! I found the article that descrives refactoring height light on ios, android, and CSS
CSS updated feature “leading trim” CSS Inline Layout Module Level 3
Wow, this is actually super helpful and even has some good solutions like selecting fonts that are properly centered, as well as finding and using the ratio of baseline to bounding box as a CSS mixin. Thank you so much!
For web, you can use Capsize until it is supported across all browsers.
This is also a great solution. I love that you can put in a grid size. Thank you!
Any luck implementing this proposed solution with your devs?
We have the same issue and it has caused severe frustration - we updated our designs with vertical trim (of course across 6 different brands 
), and as you mentioned we have to rework everything now.
Feel like this is a massive oversight by Figma, there should have been a big disclaimer attached to this.
Thank you for the validation! Yeah, pretty weird to launch a feature that really should not be used. I didn’t even try to use this after figuring all this out, I just totally avoided it.
The suggestions above were all good, and in the future I may try using the baseline / line-height ratio as a css calc rule, but until Leading-Trim goes prime time I think they should pull it.
Thanks for the info. I was wondering about this too, hopefully it gets perfected at the dev side in the near future. I’ll avoid it till then.
I went down the rabbit hole on this today, as a presentation layer savvy dev caught it. Lots of helpful stuff here in this thread, and I do wonder the point in implementing a feature that essentially makes a design so difficult to reproduce without draft properties.
Same issue. Designed a site using this feature, then wondered why it wasn’t working in code. Checked caniuse.com, which shows these properties are unsupported in everything but Safari Preview.
Figma isn’t faking this effect as an earlier poster suggested, if you switch to dev mode the unsupported CSS props are right there—
leading-trim: both;
text-edge: cap;
Agree that there should be a disclaimer/labs for experimental props. Love that Figma is getting ahead of the curve, but IMO only usable CSS should be generated by default.
This is especially true as the official documentation says “Do not implement”. Even this CSS property’s name isn’t set in stone (it changed from leading-trim to text-box-trim).
https://drafts.csswg.org/css-inline-3/#issue-00f1b914
This feature, while super useful and desired, should not be surfaced yet, as it makes the dev handoff process trickier.
I agree this feature should come with a disclaimer. Just wanted to make a point that this is not yet a feature of CSS for web implementation but it’s possible in other technologies and platforms (e.g. apps). I suppose that’s why Figma decided to implement it already.
I discovered there are @font-face properties in all browsers since 2021 to control the ascent/descent height.
Here’s as far as I got with that approach:
So you can see, it works for the h1 style - but for some reason, it falls apart if you set the line-height as in the h2 style.
I was not able to find an approach that works if you increase the line-height - unfortunately, the ascent-override and descent-override accept positive percentage values only, and with any non-standard line-height, 0% is not enough to close the gap. (I don’t know what these properties were intended for, but they don’t appear to work for this.)
And, of course, this does not work in Safari. (because we can’t have nice things. thanks, Apple.)
I found this tool, which uses pseudo-elements to close the gap:
https://text-crop.eightshapes.com/
I guess you could just do it with negative margins on the elements as well - as long as you don’t need to use a background. (because the background would paint outside your intended area.)
If you’re waiting for leading-trim, you could be waiting for some years, so it’s really down to finding the least bad of these available options.
I would love to hear from anyone else who has attempted to solve this.
I spent way too much time on this, so I’ll just share my results.
That eightshapes.com tool, it doesn’t actually seem to solve the problem - it offers parameters to adjust the top/bottom cropping manually, on top of the already-adjusted values, which tells you they knew it doesn’t really work. By which I mean, it doesn’t work for different line-heights. It seems really complicated for what it does.
I then discovered the newer lh unit, which supposedly gives you a unit that is relative to the font-size and line-height. From my testing, it does change relative to both font-size and line-height, but it doesn’t do so at the correct rate for the line-height. (go figure.)
I finally opted for just using negative margins on the text elements - you can see this working here:
So you have to manually find first the margin-bottom, and then the margin-top, for a given font at a specific line-height.
It’s a pain, but it is relatively simple, as you can see.
In practice, you would probably want to create mixins for your font-family, line-height, and margin combinations, so you can reuse them.
(At the bottom of my fiddle, you can also find a commented-out version using lh rather than em units. I opted for em in the end, because as mentioned, lh units, while they do respond to line-height, they do not appear to do so at the correct rate. Please experiment with this, if you think I’ve made a mistake? I feel like there is something I don’t understand about the lh unit and perhaps it ought to work, but I couldn’t figure it out…)
