Measured in characters, not pixels

A lesson from UI and UX for Engineers: Decisions You Made By Accident. Play it above, or read it through below.

• The measure is a preference, and preference does not track performance.

  The common read: 45 to 75 characters is the researched optimal line length, and 66 is the measured ideal.

  The sentence everyone cites contains the words "is widely regarded as", and it contains them twice. Bringhurst writes that anything from 45 to 75 characters is widely regarded as a satisfactory length for a single-column page set in a serifed text face, and that the 66-character line is widely regarded as ideal. He cites nobody, the subject is print, and the book's own justification is a copyfitting table and a rule of thumb.

  The screen studies point the other way on speed. The review that synthesises them states that most studies on line length report faster reading with longer lines. One study at 25 to 100 characters found the longest read fastest; another at 35 to 95 found 95 significantly faster; a third at 45, 76 and 132 found no significant difference in reading time at all, and recommended 65 to 75 on stated preference.

  That leaves one finding that is worth more than the number, and it is the reviewer's own sentence: subjective judgements of text format on screen have not been in close agreement with objective performance measures. Longer lines may be read faster and people prefer a moderate length. The reviewer even offers the mechanism, that the preferred range may be preferred because it is familiar from print.

  That arrives as a redesign validated entirely on satisfaction scores, shipped, and followed by a quiet regression in time-on-task that nobody connects to it, because the study that would have caught it was replaced by a survey. Keep the measure. Defend it as comfort, which is what it is and what a century of preference data supports, and stop attaching it to a speed claim, because the first person who checks will find the studies say the opposite.

• Sixteen is a default, and the good argument for it is not the one you were given.

  The common read: 16 pixels is the minimum accessible body size, and shipping smaller is a conformance problem.

  Sixteen pixels is not a minimum, it is a default, and the difference is the whole argument. The CSS absolute-size keyword medium is defined as a user's preferred font size, used as the reference middle value, and every other keyword scales from it. WCAG names no font size anywhere. The only floor the reference documentation states is that the smallest font size should not be less than 9 pixels, and Apple's own guidance says text should be at least 11 points.

  So the rule people enforce does not exist, and something better does. If a user has not changed their browser's font size, 16 pixels is the size they implicitly accepted. Shipping body text at 14 is overriding a preference they expressed by omission. That is a real argument, it survives contact with the specifications, and it is stronger than a citation to a rule that a reviewer cannot name.

  It also has an edge the folklore version does not. The argument is about the ROOT size and the user's control of it, which is why the unit question follows from it rather than the other way round: rem inherits the preference and px ignores it. The reason to prefer rem for type is not that px is deprecated, and it is not that rem renders differently. It is that one of them is anchored to a value the user owns.

  That arrives as a review comment saying "16px minimum per WCAG", on a component that is fine, from a reviewer quoting a rule that is not in the document, while the same product's hero sits at a viewport unit that no zoom can rescue. Make the argument you can actually defend, and spend the review attention on the two criteria that are real, which is where the next screen goes.

• Two criteria are about what the reader changes, and one unit breaks both.

  The common read: rem is the accessible unit, so a fluid type scale built from clamp with a vw middle term is the accessible way to size text.

  Two criteria govern what happens when a reader makes the text bigger, and one named failure technique says a unit you probably shipped this year breaks both. SC 1.4.4 Resize Text, Level AA, requires that text can be resized without assistive technology up to 200 percent without loss of content or functionality. SC 1.4.10 Reflow, Level AA, requires no two-dimensional scrolling at a width equivalent to 320 CSS pixels.

  The 320 is not a phone. The Understanding document says it corresponds to a desktop browser window of 1280 pixels zoomed to 400 percent, and the companion height of 256 pixels is 1024 at the same zoom. A criterion most engineers read as a mobile requirement is a magnification requirement, which is why a layout can pass every device test and fail it.

  The failure technique is the sharp end. F94 names sizing text in viewport units as a failure of 1.4.4, because those units are relative to the viewport and cannot be resized by zooming or adjusting text size, and its own example is a one-line rule setting a font size in vw. A clamp() with a vw middle term inherits that, and carries a second trap: a maximum lower than twice the minimum caps the reader below 200 percent by construction.

  That arrives as a support ticket from one user, closed as not reproducible by three people testing at 100 percent on 27-inch monitors, and never connected to the release that converted the stylesheet to rem for accessibility. Test at the numbers the criteria name: 200 percent, then 400 percent at a 1280-pixel window, and look for the two things they name, which are clipping and horizontal scrolling.

• Size is the lever that moved. Spacing was not.

  The common read: Longer lines need more leading, and a leading scale tuned per breakpoint is the research-based way to set body text.

  Which typographic variable has actually been shown to change reading? Not the one with the elaborate matrix behind it. The largest modern experiment on this varied six font sizes and four line spacings across 104 participants with eye tracking, and reported that line spacing had only minimal effects, with weak evidence that the extremes of 0.8 and 1.8 may impair readability. Comprehension was significantly lower at 10 and 12 points, and mean fixation duration fell continuously with size up to 18 points.

  The rule the industry teaches about leading and measure is, in the review's own words, untested. Long lines are SAID to need more interlinear spacing so the return sweep lands accurately. The review's verdict is that increasing interlinear space might help and that this has not been explored, and that the limited studies are from the early 1980s and are inconclusive.

  There is a sharper version of that and it is a methodological argument rather than a gap. As line length increases without a corresponding increase in leading, the ratio between the two changes, so any difference attributed to the longer line might be due to the reduced relative leading. The rule everyone teaches may be a confound inside the very studies the measure range is quoted from.

  That arrives as a type system with a leading value per breakpoint per role, defended in review as research-based, consuming the attention of two people for a week, on a product whose body text is 14 pixels. Spend the effort where the measurement is: make the text bigger. The one variable with a modern experiment behind it is the one nobody argues about, because it is not interesting enough to argue about.

• The engine decides, and it stops deciding without telling you.

  The common read: text-wrap: balance evens out my paragraphs, so putting it on body copy in a reset improves every block of text on the page.

  The specification hands the whole algorithm to the engine, and says so in as many words. balance chooses line breaks to balance the remaining space in each line box if better balance than auto is possible, the exact algorithm is user-agent defined, and the specification permits an engine to treat the value as auto past ten lines. That last clause is the whole beat: the property is defined to be allowed to do nothing.

  The ceiling is real and it is not one number. This lesson measured Chromium 151 balancing at 6 lines and not at 7. The reference documentation reports six or fewer for Chromium and ten or fewer for Firefox. Chrome's own article says six. WebKit's says Chromium limits it to four and that its own implementation needs no limit at all. Four numbers, four sources, one property.

  pretty is the body-copy value and it also differs by engine today. Safari 26, September 2025, evaluates the whole paragraph, and describes its own goal as preventing short lines, improving the rag and reducing the need for hyphenation across all of the text no matter how long it is. Chromium adjusts only the tail. Same declaration, materially different typography, right now.

  That arrives as a developer adding the declaration to p in a reset, seeing nothing change, concluding the property is broken, and never using either value on the headings and pull quotes where one of them works. Treat both as progressive enhancement and never as layout: put balance on short things, put pretty on prose, and check the line count before believing that a declaration you can see in the stylesheet is doing anything at all.