Multiline clamp must recast with type size, not a fixed pixel height
Aliases: line-clamp · multiline ellipsis · lineLimit
What it is
“Preview three lines” is a promise about lines, not about a pixel box. A line-clamp or a platform line limit lets that preview grow as type grows. A hard-coded height that hides overflow does not: as type enlarges, three lines become one and a half, and a glyph is sheared on the box edge. Line clamp versus fixed pixel height is about the unit of the constraint. The unit should be lines. A height measured off a default-type canvas is the wrong unit.
Why it happens
A line box is roughly type size times line-height. A fixed pixel height comes from an artboard at default type and knows nothing about a later user scale. How many lines fit is height divided by line box, rounded down. From a regular setting to the largest accessibility bucket, the line box can more than double, so a “three-line preview” inside a pixel box becomes two lines, then one line plus a chopped glyph. Some implementations clip without drawing an ellipsis, so nothing even signals that copy continues. A line-count clamp decides which line to drop after wrapping, and the box grows with the lines, so the preview’s meaning — at most three lines — still holds after type changes. Whether the rest of the layout is shoved aside is a container-versus-scale problem; this claim is only that truncation itself counted in the wrong unit.
Where it stops holding
Single-line ellipsis is a different trigger: width, not a pixel height used as a line counter. Titles overlaid on a poster or thumbnail sometimes have to live inside the image’s height; that is an overlay bargain, and it wants a dedicated short title rather than pretending to be a reflowing preview. A line cap can itself fill the screen at extreme type, in which case the preview should become a scroll region or yield to the full article — not quietly revert to a pixel lock. Browser zoom and system Dynamic Type both resize the line box; testing only one of them misses the other.
Applying it
- Drive preview blocks from a line count and let block height grow with type. Do not fake three lines with a fixed height and hidden overflow.
- Crank system type to the largest bucket and count remaining whole lines in every clamped preview. The intended count should still be there, or the block should scroll as full text. A sheared glyph is a fail.
- When line-height scales with type, do not hard-code the cap as “divide by 24 pixels.” Recompute from the actual line box.
Related
- Same group: F4.10.1 Where a string is cut decides whether the leftover is still usable · F4.10.2 Middle ellipsis keeps the distinctive start and end · F4.10.3 Truncated copy still needs a path to the full string · F4.10.4 Decision-critical text such as prices and warnings must not be truncated · F4.10.5 Assistive technology must still receive the untruncated string · F4.10.6 CJK characters pack more meaning per glyph, so the same character budget loses more
- Nearby: F4.09 Dynamic Type · F4.16 Dynamic Type and user font size · F4.02 Leading
- Search terms:
line-clamp·Dynamic Type·multiline truncation
Cards in the same group
- F4.10.1Where a string is cut decides whether the leftover is still usable
- F4.10.2Middle ellipsis keeps the distinctive start and end
- F4.10.3Truncated copy still needs a path to the full string
- F4.10.4Decision-critical text such as prices and warnings must not be truncated
- F4.10.5Assistive technology must still receive the untruncated string
- F4.10.6CJK characters pack more meaning per glyph, so the same character budget loses more