Measure and Line Length

You built a type scale in Chapter 01. Every font size has a name and a source. The next problem is one most pages get wrong without anyone noticing: how wide a line of text should be.

Look at the default behavior. A content container with width: 100%, or a generous pixel max-width like 1200px, lets paragraph text run the full width of the column. On a wide desktop monitor, that produces lines of 90, 110, sometimes 130 characters. It looks fine in a design tool at a fixed canvas size. It reads badly in a browser at full width.

The reason it reads badly has nothing to do with taste.

What measure is, and why 65

“Measure” is the typographic term for the length of a line of text. It predates the web by a few centuries. Book typographers have a working rule that the comfortable range for sustained reading is roughly 60 to 75 characters per line, counting letters, spaces, and punctuation. It’s a longstanding guideline, not a recent finding.

The mechanics behind it are simple. When a line is too long, your eye loses its place on the return trip. You finish one line, sweep back to the left margin, and land on the wrong line, or re-read the one you just finished. When a line is too short, your eye returns so often that the rhythm of reading breaks up. The 60 to 75 range is the span where the return sweep stays reliable and the rhythm holds.

For a single practical target, 65 characters works well. It sits in the middle of the range and leaves room on either side.

The ch unit

CSS has a unit built for this: ch.

One ch is the advance width of the 0 glyph (zero) in the element’s current font. Not the width of an average character, and not a literal character count. In a proportional font, m is much wider than i, so a container sized at 65ch will not hold exactly 65 characters of running text. It holds roughly that many. The 0 glyph happens to be close to the average character width in most text fonts, which is what makes it a useful stand-in.

So 65ch is an approximation. That’s fine. You’re not counting characters, you’re constraining a column to land inside the comfortable range, and an approximation does that job.

.prose {
  max-width: 65ch;
}

That one line solves the problem the width: 100% container created.

The font dependency

There’s one property of ch worth understanding before you rely on it. The unit is font-dependent. Because it’s measured from the current font’s 0 glyph, the computed pixel width of 65ch changes if the font changes. A condensed font produces a narrower 65ch. A wide font produces a wider one.

In practice this rarely causes trouble. The font on your prose container is usually set at the same level as the width constraint, or inherited from a parent that set it. The ch value and the font it depends on travel together. If you swap the body font later, the measure adjusts with it, which is the behavior you want anyway. Be aware of the dependency. It’s a feature far more often than a bug.

Putting it with the scale

The measure constraint lives alongside the type scale from Chapter 01, not instead of it. The scale sets how big the text is. The measure sets how wide the column is. A .prose utility class is the right place to hold both, plus anything else that defines reading content:

.prose {
  max-width: 65ch;
  font-size: var(--text-base);
}

.prose p {
  margin-block: 0 1em;
}

Apply .prose to the wrapper around any block of long-form text. Article bodies, documentation pages, product descriptions, anything read paragraph by paragraph. The font size comes from the scale token. The width comes from ch. One class, and the reading content is handled.

Where measure applies, and where it doesn’t

The 65-character rule is for reading content. Body paragraphs, article text, anything a person reads sentence after sentence. That’s where a controlled line length earns its keep.

It does not apply to every text element on the page. Navigation links, image captions, pull quotes, button labels, table cells, form labels: none of these are sustained reading. A nav item is two words. A caption is a phrase. Capping them at 65ch does nothing useful, and forcing a pull quote into a narrow column can fight the design. Don’t reach for .prose reflexively. Reach for it on the parts of the page that hold prose.

Measure and leading

One thing worth flagging now, because it changes the answer you’d otherwise reach for in this chapter. Line length and line-height are connected. A wider line needs more space between lines to keep the return sweep reliable, because the eye has farther to travel back. A narrow line can take tighter leading.

So max-width is only half of the reading-comfort decision. Chapter 03 covers line-height in full. For now, set the measure and know that the leading is the other lever.

When the container is already narrow

A reasonable worry: what happens when a .prose element sits inside something narrower than 65 characters, like a card or a sidebar?

Nothing bad. max-width is a ceiling, not a floor. If the parent is 40 characters wide, the prose block fills 40 characters and stops there. 65ch only takes effect when there’s room for it. You don’t need a min-width, and you don’t need a media query to handle the narrow case. The constraint already does the right thing: it caps wide columns and leaves narrow ones alone.

That’s the whole technique. One max-width on the containers that hold prose, expressed in ch, sized to 65. The line length stops being something you eyeball per layout and becomes something the stylesheet enforces everywhere prose appears.

In Chapter 03, you’ll set the leading that this measure depends on.