Skip to main content
Question

Text layer height and Vertical Trim do not map clearly to browser CSS line boxes

  • September 4, 2026
  • 1 reply
  • 7 views
ahao

Hi Figma team,

I am reporting a recurring design-to-code mismatch around text box height. A Figma auto-height text layer and a browser DOM element can have different outer heights even when the typography panel shows the same font family, font size, font weight, and an explicit pixel line-height. This changes Auto Layout/component heights and makes one-to-one Dev Mode handoff ambiguous.

1. Line-height is not enough to identify the measured box

In CSS, line-height participates in line-box layout; it is not necessarily the height returned for a non-replaced inline element. For example, in current Chromium, with:

font-family: Arial, sans-serif;
font-size: 16px;
font-weight: 400;
line-height: 24px;
margin: 0;
padding: 0;
border: 0;
  • an inline <span> has computed line-height 24px, but getBoundingClientRect().height is 17px;
  • the containing line box is 24px high;
  • the same element as inline-block or block is 24px high.

Figma and Dev Mode expose a text-layer height and line-height, but do not make clear whether that height corresponds to CSS line-box height, font/ink bounds, an inline DOMRect, or Figma-specific canvas font metrics. This regularly causes designers and developers to compare different boxes while believing the values are equivalent.

2. Vertical Trim documentation and CSS mapping appear outdated

The current Figma help page says that Vertical Trim appears in Dev Mode as leading-trim: both and translates to leading-trim and text-edge. Those were draft names. Current CSS uses:

text-box-trim: trim-both;
text-box-edge: cap alphabetic;

/* shorthand */
text-box: trim-both cap alphabetic;

Chrome documents this syntax from Chrome 133, and the related browser/Figma mismatch has already been discussed in the forum. The linked WebKit issue was closed as INVALID; a CSS specification editor explained that trimming to cap height and alphabetic baseline requires those metrics to be declared explicitly.

Expected behavior / request

  • Dev Mode should explicitly distinguish Figma text-layer bounds from CSS line-box height and inline-element DOMRect/ink bounds.
  • Vertical Trim should emit the current standards-track text-box-trim/text-box-edge syntax, or clearly document the exact modern CSS needed to reproduce each Figma trim mode.
  • If Figma intentionally rounds trimmed text bounds to whole pixels while browsers preserve subpixels, Dev Mode should disclose that difference.
  • For Vertical Trim off, please document which font metrics Figma uses for the first and last line so that developers can reproduce Auto Layout heights reliably.

Related reports and references

Could the team confirm the intended mapping between a Figma auto-height text layer and the browser CSS box model, and whether Dev Mode/help documentation will be updated to the final text-box syntax?

1 reply

ahao
  • ahao
  • Author
  • New Member
  • September 4, 2026

Additional case: Figma Auto line height is not equivalent to Chromium line-height: normal

The original post intentionally used an explicit 24px line-height to isolate the box-model issue. A second, separate mismatch occurs when a Figma text layer uses Auto line height while the browser uses line-height: normal, even when the exact same font file, font size, weight, text, and width are used.

Figma's documentation says Auto is calculated from the font's default line height. In CSS, however, normal is a user-agent-defined value rather than a portable numeric value. Chromium resolves the font's vertical metrics through its own text engine, and Figma can resolve or round those metrics differently. Therefore the two keywords can produce different baseline spacing and different block/Auto Layout heights despite apparently identical typography settings.

A useful apples-to-apples test is:

  • Figma: exact font file and weight, fixed font size, line height Auto, Auto height, Vertical Trim off.
  • Chromium: the same font file loaded with @font-face, the same size/weight/text/width, line-height: normal, display: block, and no margin, padding, or border.
  • Wait for document.fonts.ready, then compare both baseline-to-baseline distance on multiple lines and the outer box height.

Request: Dev Mode should not imply that Figma Auto maps one-to-one to CSS normal. Please expose the numeric line height that Figma actually resolved (including subpixels), and ideally identify which font metrics are used. For web handoff, Dev Mode could output that explicit value or display a warning that CSS normal is browser-dependent.

Related reports:

Terms & ConditionsAccessibility statement