Vertical rhythm, and why the strict version fails on screen

The idea

A baseline grid is a set of evenly spaced horizontal lines — say every 24 pixels — that every line of text sits on. Body text, captions, headings and list items all land on the same lines, so that two columns side by side have their text in register and the page has an even vertical beat.

In print this is real craft and it is achievable. It is also old: in letterpress and in fine book printing, register-true setting meant the lines on the back of a leaf fell exactly behind the lines on the front, so that thin paper did not show a shadow of misaligned text. InDesign has a baseline grid; so does Scribus, which is free and open source, under File > Document Setup > Guides. LibreOffice Writer offers register-true paragraph styles.

Why it mostly does not survive the web

Four mechanisms break it, and it is worth knowing them precisely rather than concluding that web typography is simply careless.

1. The half-leading model. In CSS, when the line height exceeds the font's natural line box, the surplus is split equally above and below the text. Where the baseline falls inside that box depends on the font's internal metrics — ascent, descent and line gap — which differ between families and are not exposed to you in any convenient way. Change the typeface and every baseline moves by an amount you cannot easily predict.

2. Arbitrary content heights. An image is whatever height it is. A video embed, a code block, a map, a third-party widget — none of them is a multiple of 24 pixels, and a single one pushes everything after it off the grid for the rest of the page.

3. Form controls. Inputs, selects and buttons are rendered partly by the operating system and have platform-specific metrics. A select on Android is not the same height as one on iOS.

4. Reflow. The page is a different width on every device, so line counts change, and anything whose height depends on wrapping changes with it.

You can fight all four. People do, with line-height set in fixed multiples, calc() on every margin, and images forced into fixed-ratio boxes. The cost is real: brittle layouts, awkward image sizing, and a lot of arithmetic maintained by hand for a benefit almost no reader can articulate.

What to keep

The valuable part of vertical rhythm survives without the strict grid, and it is this: vertical space should come from a small, consistent set of values that relate to the line height.

Concretely, if your body line height is 24px:

• Use 24 and 48 as the main vertical gaps, with 8 and 16 for tight relationships.
• Give every text element a line height that is a clean multiple where you can — 24px body, 24px captions at a smaller size, 48px for a large heading.
• Set headings with more space above than below, because a heading belongs to what follows it.

This gets you the even beat that readers actually perceive — a page whose vertical spacing feels considered — without the brittleness. Nobody has ever noticed that a paragraph after a photograph is three pixels off a grid. Everybody notices a page where the gaps are 19, 26, 31 and 44.

Where the strict version is still worth it

• Print, where the page is fixed. A book, a report, a programme, a menu. Scribus will hold the grid and the result is visibly better in multi-column settings.
• Multi-column text on a fixed-width screen, such as a kiosk or a generated PDF.
• Long documents with side notes, where a note must align with the line it annotates.

Everywhere else, the honest answer is that strict baseline alignment is a cost with a small and mostly invisible return, and that the people who tell you otherwise are usually showing you a screenshot of a page with no images in it.

A note on line height inheritance

One practical trap while you are setting this up. A unitless line height — line-height: 1.5 — is inherited as a ratio and recalculated against each element's own font size. A line height with units — line-height: 24px — is inherited as a fixed value, so a 32px heading inside that container gets 24px lines and the letters collide.

Set a unitless value on the body and override it explicitly on headings. This is the single most common cause of headings whose lines overlap, and it costs one character to fix.