Constrain measure in characters, not pixels
Aliases: cpl · ch unit · character measure
What it is
A column written as 600 pixels holds a different number of characters as soon as size changes, the face changes, or the user enlarges type. Both “too long” and “too short” are about eyes and language units. Their real scale is characters per line, not pixel width on the screen. Pixels constrain the box. Character count constrains how far a return has to travel and whether a phrase will be cut.
Latin traditionally counts letters or words per line; Chinese counts characters. CSS ch is relative to the width of the glyph “0”: more honest than pixels for roughly square Han, only an approximation for proportional Latin. Either way the intent is the same: measure follows the writing, not the artboard.
Why it happens
The same pixel column that swallows seventy-odd Latin characters at 12px may hold a little over forty at 18px. The first is already sliding long; the second may be fine. If the product nails the column in pixels, the type scale, Dynamic Type, and language switches rewrite effective measure behind the user’s back: English still sits in the comfort band, German words run longer, Chinese characters run wider, and the same box is suddenly cramped or empty.
Width of the face rewrites the count too. A condensed display gothic and a wide text Song put different numbers of glyphs in the same pixel run; tabular figures and fullwidth punctuation eat more cells. So “body column 680px” can exist as an implementation detail; it cannot be the design intent. Intent has to say “about this many characters of body,” with pixels as a projection under one face and one size.
When the user enlarges type and the column stays pixel-fixed, characters per line fall, the paragraph slides from the comfort band toward too-short, and wraps start to interrupt. If the column is in character units, or grows with the type, the count stays roughly stable and the long/short judgement still means something.
Where it stops holding
Pictures, video, and maps are not text columns; they can stay in pixels or viewport fractions. Buttons, labels, and single-line fields take their width from the control and the hit target, not from prose measure. Monospaced code is most naturally capped in characters, but those numbers come from language convention (80 or 100 columns) rather than a reading-return comfort band. Mixed columns — image left, caption right — let the image’s pixel width drag the caption’s character count; the fix is to change the layout at the breakpoint (stack the image) rather than pretend a pixel cap equals a reading cap.
On an extremely narrow screen there are not enough physical pixels for the target count. Character count is then a diagnostic: it tells you the line is already short. The choices are drop size, drop padding, or accept short lines and fix leading — not to keep claiming “we are 680px, so we are fine.”
Applying it
- Write the body-column intent as characters per line (separate numbers for Latin and Chinese). Implementation may approximate with
ch,em, or “size × a factor”; do not leave only a pixel mark on the mockup. - Recount actual characters per line at every type-scale rung and after system enlargement. Do not assume a pixel column still equals the old reading measure.
- Accept English and Chinese (and German) separately: the same pixel box holds fewer Han characters and longer German words, so the long/short thresholds move.
- How to check: paste a body paragraph at default size and at the largest commonly used enlargement, and count characters on the first three lines. If all three land in the same count band, the constraint is following the type. If only the pixels match and the counts jump, the column is nailed to the artboard.