Optically centring button text with text-box

Because a line's box does not end at the type but at the measurements the font file specifies. Above the capitals there is room for accents such as Ä or É and for ascenders, below the baseline room for the descenders of g, p and y. On top of that comes the share of line-height, added in equal parts above and below. In a button with a word in capitals or with a capital initial, the space at the top is almost always empty, the one at the bottom too, but it is smaller.

You can see the result on every button with equal padding: the distance from the top edge to the letters is larger than the distance from the baseline to the bottom edge. How large the difference is depends entirely on the typeface. That is why no fixed rule such as one pixel more at the bottom helps: it holds for one font at one size and is wrong at the next change.

The usual corrections all start in the wrong place. Unequal padding moves the text, but only for that font size. A negative margin on the text element moves the line, but the layout around it keeps calculating with the old height. And line-height set to 1 shrinks the line evenly according to the font's metrics, not according to what you see.

It cuts away the space between the edge of the box and the visible type, at the top of the first line, at the bottom of the last one, or both. Where exactly it cuts is set by text-box-edge. With cap the box ends at the top at cap height, with alphabetic at the bottom at the baseline. After that, the padding is the distance you also see.

The text-box shorthand combines both. text-box: trim-both cap alphabetic cuts at cap height at the top and at the baseline at the bottom, and because missing parts are filled in, text-box: cap alphabetic is enough. The initial value is normal, meaning no cut. The property is not inherited and applies to block containers and inline boxes.

Safari shipped it first, in version 18.2, Chrome in version 133. Firefox has supported it since version 154 according to caniuse, and MDN has listed it as Baseline since August 2026. Early drafts called it leading-trim, and older posts still show examples under that name that no longer work today.

For buttons, labels and headings cap alphabetic is almost always the right choice. Most labels start with a capital or consist entirely of them, and the eye measures the space at the top at exactly that edge. At the bottom it measures at the baseline, not at the descenders, which may reach into the padding with a g or a y.

Text set entirely in lowercase is different. There are often no capitals for the eye to orient itself by, and the visible top edge sits at x-height. For that case there is ex as the top edge. A button labelled next or a tag in lowercase then sits in the middle where cap would show it too low.

The third edge, text, matches the font's starting state and is useful where you only want to cut one side. With trim-start or trim-end you can, for example, cut only the top of a heading so it starts flush with an image beside it, while the space to the following paragraph stays the same.

Because the property applies to block containers and inline boxes, and a flex container is neither. Many buttons use inline-flex so that icon and text sit side by side, centred. The text inside then ends up in an anonymous flex item, and because text-box is not inherited, the declaration on the button never reaches that text.

The fix is a dedicated element around the label, usually a span, and the declaration belongs on that element. An inline box is explicitly included, and as a flex item the span becomes a block anyway. The button keeps its inline-flex, the icon stays centred through align-items, and only the text loses the empty space above and below it.

On a button set to inline-block this is not needed, because an inline-block is a block container. The easiest way to check is in the browser: in the developer tools the box view shows the height of the text element, and with the cut it has to be visibly smaller than without.

Anywhere text should line up with a visible edge. The most common example is a card with image and heading side by side: without the cut the heading starts a few pixels below the top of the image, even though both sit on the same line in the grid. With trim-start cap, cap height lines up flush with the image.

The second example is spacing between heading and text. A gap of 16 pixels in code is often 22 or 24 on screen, because there is invisible font space below the heading and above the paragraph. Cutting both sides gives you the gap the layout specifies, and a spacing system made of a few values actually becomes visible on the page.

The third is small elements with a background: tags, counters in a circle, figures in a tile. The offset is most noticeable at small sizes, because a few pixels make up a large share of the height. A counter with a single digit in a circle sits in the middle with cap alphabetic, without anyone nudging it by hand.

Nothing that looks broken. A browser that does not know text-box skips the declaration and shows the line as it looked before, with the slight downward offset. So the property adds something on top, it replaces nothing, and an @supports query is not needed for the simple case.

A query is only worth it when the padding is tuned to the cut and would be too large without it. Then you write the padding for the untrimmed version as the default and put the smaller or larger padding together with text-box in an @supports (text-box: cap alphabetic) block. That way every browser gets the height that suits its behaviour.

Two looks are enough to check. In a current browser the space above the capitals has to equal the space below the baseline, easiest to see with a word without descenders like START. In an older browser the button may sit a little lower, but not so tight that the type touches the edge.