Can CSS Finally Fix Vertical Text Spacing?

Has CSS finally fixed the gap above and below your text?

As of September 2026, yes, and it is newer than most teams realise. MDN lists both text-box-trim and text-box-edge as Baseline 2026 newly available, working across the latest browser versions since August 2026. That is roughly one month of interoperability, which makes this the freshest useful thing in CSS typography.

The problem it solves is the one every designer has complained about and every developer has bodged. A heading sits in a box that is taller than the letters, so the space you measured in the design is not the space that appears in the browser.

Two properties now address it directly. Here is what they do, what the Baseline label promises, and whether it is safe to use on a client site yet.

What is the problem being solved?

Fonts carry space you did not ask for. Every font has metrics describing how far its letterforms sit inside the line box, and that leftover space appears above and below the visible text. MDN describes the purpose of the new property as helping "achieve consistent vertical spacing of text by removing extra space above and below text that varies between fonts".

The phrase that matters there is "varies between fonts". The gap is not a constant you can subtract once. Change the typeface and the gap changes, which is why a font swap during a rebrand quietly shifts vertical rhythm across an entire site.

It compounds with line height. Raising line-height for readability adds half the extra space above the first line and half below the last, so a paragraph with comfortable line spacing has visible padding baked into its edges that nobody specified.

What do text-box-trim and text-box-edge do?

They split the job in two. MDN describes text-box-trim as specifying "which of the over and under edges of text content to trim from a text element's block container", and text-box-edge as specifying "an amount of space to trim from a text element's block container".

So one property picks the edges and the other picks how deep to cut. MDN puts it simply: text-box-edge "specifies how much space to trim", working "in conjunction with" text-box-trim. Both can be set together with the text-box shorthand.

They are also strictly paired. MDN notes that text-box-edge "has no effect if text-box-trim is not set or is set to none". Setting the depth without choosing an edge does nothing at all, which is the first thing to check when it appears not to work.

What are the values you would actually use?

A small set. text-box-trim takes none, which is the default, plus trim-start to trim the over edge, trim-end to trim the under edge, and trim-both for both.

text-box-edge defaults to auto, which MDN says is equivalent to text. Given two values, the first applies to the over edge and the second to the under edge. Valid over edge values are text, cap, ex, ideographic and ideographic-ink. Valid under edge values are text, alphabetic, ideographic and ideographic-ink.

The combination most designers want is cap for the top and alphabetic for the bottom. That trims flush with the top of the capital letters and flush with the baseline, which is exactly how a typographer measures a block of text, and exactly how it was measured in the design file.

What does Baseline 2026 newly available mean here?

Interoperable now, not universal. Baseline defines newly available as a feature that "is supported by all of the core browsers, and is therefore interoperable", where the core set is Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

The second stage is the one that means safe by default. Baseline says a feature becomes widely available once "30 months have passed since the newly interoperable date", at which point it "can be used by most sites without worrying about support".

August 2026 plus 30 months puts that in early 2029. So today's honest position is that current browsers all handle it and a meaningful share of real visitors are not on current browsers. That is a fine position for a visual refinement and a poor one for anything load bearing. We apply the same test to every new feature, as set out in how to read Baseline before you ship.

Where does this change a real design?

Anywhere text sits inside a box you sized. Buttons are the clearest case: a label that looks vertically centred in the design sits slightly high in the browser, because the font's descender space pads the bottom. Trimming both edges makes the padding you wrote the padding you see.

Cards are the second. A card with 24 pixels of padding and a heading at the top has more than 24 pixels of visible space, and the amount depends on the typeface. Multiply that across a grid and the layout reads looser than intended.

The third is the gap between a heading and the paragraph under it. That gap is the margin you set plus two font-dependent slivers. Trimming makes typographic spacing behave like the numbers in your design system rather than a suggestion. The broader thinking on that spacing sits in using white space deliberately.

What did teams do before this?

Subtract by hand. A negative margin on the heading, a tweaked line height, a magic number in a utility class with a comment saying it compensates for the font.

All of those work and none of them survive. They are tied to one typeface at one size, so they break on a font change, on a fluid type scale, and on any component that reuses the style at a different size. We have all shipped them and we have all had to unpick them.

The new properties are better because they are declarative about intent. "Trim to the cap height and the baseline" stays true when the font changes. "Subtract 4 pixels" does not.

Does this change the design handoff?

It closes a long running argument, which is the underrated benefit. Designers position text by its letterforms because that is what they can see. Browsers position text by its line box. Those two measurements have never agreed, and the difference has been absorbed by whoever built the page.

With trimming available, the two can finally mean the same thing. A spacing value in the design file can be implemented as that value, with no silent adjustment and no negotiation about whose measurement is correct.

That is worth writing into your design system documentation rather than leaving as a per-component decision. If the system says headings trim to cap and baseline, every spacing token downstream becomes meaningful. Our wider approach to type on the web is in web typography and font choices.

How would you adopt it safely today?

As pure enhancement, with no layout depending on it. Set the trim on your heading and button classes and accept that older browsers get the current, slightly looser spacing. Nothing breaks. The page is marginally less tight, which is the state it has been in for twenty years.

What we would avoid is designing spacing so tight that it only reads correctly with trimming applied. That turns a progressive enhancement into a requirement, and the fallback becomes visibly wrong rather than merely different.

Test with your actual brand typeface rather than a system font. The whole point is that the trimmed amount is font specific, so the visual difference between trimmed and untrimmed varies by typeface, and in some faces it is dramatic.

What should CSS typography get next?

More of the same idea: metrics that designers already reason about, exposed as properties instead of approximated with arithmetic. Trimming to cap height and baseline was the largest gap, and closing it removes a whole category of magic numbers from stylesheets.

Our expectation is that in two or three years this will simply be part of every design system reset, in the same way that box sizing became a default nobody argues about. The teams that benefit first are the ones whose spacing already lives in tokens, because adopting it is one declaration rather than a component by component audit.

If your headings and buttons have never quite matched the design and you want to know whether this is why, we are happy to take a look. Find us at phoenix.studio.