Vertical Trim is nice, but without CSS support it's kind of useless. What am I missing?

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.

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.

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…)

It’s live! https://developer.chrome.com/blog/css-text-box-trim

Have you been able to use it yet? My VSCode still shows an “unknownProperties” error.