Multi-column Layouts

The decision to use multiple columns is not primarily a visual one. It is a decision about reading. A single column of text asks the reader to follow one continuous stream from top to bottom of the page, line by line, without lateral movement or comparison between parallel streams of information. Multiple columns change this fundamentally. They introduce lateral structure — the possibility of comparison, of parallel content, of information organised spatially rather than sequentially. This is a powerful capability, and like all powerful capabilities it can be used well or poorly. Most documents that use multiple columns should not. Most documents that would benefit from them use a single column instead.

This chapter gives you the criteria for making that decision clearly, the technical tools to implement multicolumn layouts in CSS, and the judgment to know which CSS mechanism — the CSS Multi-column specification or CSS Grid — is the right tool for each specific situation.

· · ·

When multiple columns are appropriate The decision framework

Multiple columns are appropriate when at least one of three conditions is true: the line length would otherwise be unacceptably long, the content benefits from spatial organisation, or the page format demands it.

Line length is the most common driver. As established in Chapter 12, a comfortable line of body text runs between 45 and 75 characters, with 66 as the approximate optimum. At typical body text sizes — 11 to 13 points — this corresponds to a column width of roughly 70 to 90 millimetres. A page wider than this cannot sustain a single column without lines becoming uncomfortably long. A landscape A4 page, a tabloid-format document, a wide-format presentation: these formats require multiple columns simply to maintain legible line lengths.

Content structure is the second driver. Some content is genuinely parallel — two versions of a text in different languages, a comparison of two sets of data, a document where notes and commentary run alongside the main text at matching vertical positions. This kind of content has an inherent spatial logic that multiple columns express naturally. Forcing it into a single column either loses the parallelism (by running the content sequentially) or creates awkward interleaving.

Page format requirements is the third. A reference book with many short entries, a dictionary, a bibliography, a price list: these are formats where the brevity of individual items and the density of information make a single column wasteful and navigationally inconvenient. Multiple short columns allow the reader to scan vertically without losing their place across a wide expanse of page.

When none of these conditions apply — when the line length is comfortable, the content is sequential, and the format is standard — a single column is almost certainly correct. The burden of proof for multiple columns is on the designer, not on the single column. The default should always be the simpler structure.

· · ·

Column width, gutter, and readability The geometry of legible columns

Column width in a multicolumn layout is constrained from both sides. The upper limit is legibility: as established in Chapter 12, lines longer than about 75 characters are uncomfortable to read, because the eye must travel too far across the page before returning. The lower limit is also legibility: lines shorter than about 45 characters are awkward, because the eye returns too frequently, disrupting the reading rhythm and creating excessive hyphenation.

In practical terms, this means that for a typical body text typeface at 11–13pt, a column should be between approximately 55mm and 90mm wide. A narrower column than this produces short, choppy lines and excessive hyphenation. A wider column produces lines that are too long for comfortable reading and, if the text is justified, irregular word-spacing as the compositor (in our case, the browser's text engine) struggles to fill lines of inconsistent word count.

The gutter — the space between columns — must be wide enough that the reader's eye does not accidentally continue from the end of one column into the adjacent column. The minimum functional gutter width is roughly one em at the body text size — approximately 11pt at a 11pt body. The preferred width is between 1.5 and 2 ems. A gutter narrower than one em is a navigational hazard. A gutter wider than 2.5 ems begins to look like two unrelated columns rather than a coherent two-column layout. A column rule — a thin vertical line in the gutter — can be used to clarify the boundary when the gutter is on the narrow side, but it is not a substitute for adequate gutter width.

The relationship between column width and gutter also determines how many columns a given page can support. A 148mm-wide text area (A5 page with standard margins) can support two 60mm columns with a 28mm gutter — barely adequate. The same text area cannot support three columns of usable width. An A4 text area of approximately 160mm can support three narrow columns with generous gutters. Column count is not a free variable; it is determined by the page dimensions and the typographic requirements.

· · ·

Spanning elements across columns Headings, images, and pull quotes

Multi-column layouts gain much of their expressive power from the ability to span elements across some or all of the columns. A full-width heading that spans all columns provides a visual anchor above the text, clearly indicating that what follows belongs together. A wide image spanning all columns creates a moment of visual pause in the reading. A pull quote spanning both columns creates emphasis and page structure without requiring a full-width break in the content flow.

In the CSS Multi-column specification, spanning is controlled with column-span: all, which causes an element to span the full width of the multi-column container, creating a break in the column flow above and below the spanning element. This is the correct tool for full-width headings and cross-column images within a multi-column text flow.

The limitation of column-span is its binary nature: an element either spans all columns (column-span: all) or spans none (column-span: none, the default). There is no way to span two columns out of three, or to span a fraction of the column width. For more precise control over which tracks an element occupies — spanning two of three columns, spanning from column two to the right edge, placing an element in a specific column regardless of the text flow — CSS Grid is the correct tool, not CSS Multi-column.

· · ·

CSS Multi-column vs. CSS Grid Choosing the right tool

CSS provides two distinct mechanisms for multi-column layout, and understanding when to use each is one of the most practically important decisions in document CSS. They are not interchangeable, and they are not in competition — they solve different problems.

CSS Multi-column (the column-count and column-width properties) is designed for flowing text. You define the column structure and the browser distributes the content automatically, balancing the columns where possible and flowing excess content to the next page in a paginated document. You do not control which content lands in which column. The flow is automatic. This makes CSS Multi-column ideal for body text that you want to flow through multiple columns — a reference section, a bibliography, a continuous article in a two-column format. It is inappropriate when you need explicit control over which elements appear in which columns.

CSS Grid is designed for explicit placement. You define the column structure and then deliberately place each element in a specific position. The browser does not make placement decisions for you. This makes CSS Grid ideal when the spatial arrangement of elements matters independently of their source order — a page where a wide image must appear in specific columns regardless of where it falls in the text flow, or a layout where the relationship between elements in different columns must be preserved.

The practical decision rule is this: if the content should flow naturally and automatically through the columns, use CSS Multi-column. If specific elements need to occupy specific column positions, use CSS Grid. For a document that mixes both requirements — flowing body text and specifically placed figures — use CSS Multi-column for the text and CSS Grid for the page-level structure that positions elements relative to the overall page layout.¹

/* ── CSS Multi-column — flowing text ──────────── */
.bibliography {
  column-count:  2;
  column-gap:    2rem;
  column-rule:   1px solid var(--rule);
}

/* Heading spans all columns                     */
.bibliography h2 {
  column-span:   all;
  margin-bottom: var(--space-sm);
}

/* Each entry stays together across column break  */
.bibliography .entry {
  break-inside:  avoid;
}

/* ── CSS Grid — explicit placement ─────────────── */
.page-spread {
  display:               grid;
  grid-template-columns: 1fr 1fr;
  column-gap:            2rem;
}

/* Wide image placed explicitly in both columns   */
.spread-image {
  grid-column:           1 / -1;
}

/* Caption placed in right column only            */
.spread-caption {
  grid-column:           2;
}

· · ·

With this chapter, Part Three is complete. The project document now has its typographic foundation (Part Two), its column structure (Chapter 13), its page geometry (Chapter 14), and its multicolumn strategy (this chapter). The next step is to give the document its temporal structure — the running headers, page numbers, break controls, and pagination logic that turn a collection of styled HTML into a paginated book. That is the work of Part Four, beginning with Chapter 16: Thinking in Pages.