readium-css

How the multicolumn layout works

[Implementers’ doc] [Authors’ doc]

Global References:

Introduction

By using columns, content can flow from one column to another, and the number of columns can vary depending on the size of the viewport. The specification was originally designed to replace table-based multicolumn layout.

You can declare a multicolumn layout with one line of CSS:

body {
  column-width: 15em;
}

Or

body {
  column-count: 2;
}

Or

body {
  columns: 2 15em;
}

The multi-column model

Multi-column layout introduces a new type of container between the content box and the content: the column box. This is a significant departure from the traditional box model.

The content of a multicol element is flowed into column boxes, which are arranged into rows, like table cells (inline direction). Consequently:

Critical shortcomings can be pointed out in the column box model:

  1. it is not possible to set properties/values on column boxes, which is why you can’t set the background of one specific column;
  2. the column box has no concept of padding, margin or borders;
  3. column boxes don’t establish containing blocks for elements with position: fixed || absolute;
  4. multicol elements with column heights larger than the viewport may pose accessibility issues.

However, floats inside multi-column layouts are positioned with regard to the column box where they appear.

Finally, since a multi-column element establishes a new block formatting context, a top margin set on the first child element will not collapse with the margins of the multicol element.

The number and width of columns

Basically, two properties determine the width of columns:

A third one, columns, is a shorthand which sets both.

Column width

This property describes the width of columns in multicol elements.

Its values can be:

The actual column width may be wider (to fill the available space), or narrower. But the column width can only be narrower if the available space is smaller that the specified column width.

Notes

Column count

This property describes the number of columns of a multicol element.

Its values can be:

It is important to note that if both ‘column-width’ and ‘column-count’ have non-auto values, the integer value describes the maximum number of columns.

Columns

This is the shorthand property for setting column-width and column-count. Omitted values are set to their initial values (auto).

Pseudo-algorithm

The pseudo-algorithm below determines the used values for column-count (N) and column-width (W). There is one other variable in the pseudo-algorithm: the used width of the multi-column element (U).

The used width of the multi-column element (U) can depend on the element’s contents, in which case it also depends on the computed values of the column-count and column-width properties. The specification does not define how U is calculated.

(01)  if ((column-width = auto) and (column-count = auto)) then
(02)      exit; /* not a multicol element */
(03)  if column-width = auto then
(04)      N := column-count
(05)  else if column-count = auto then
(06)      N := max(1,
(07)        floor((U + column-gap)/(column-width + column-gap)))
(08)  else
(09)      N := min(column-count, max(1,
(10)        floor((U + column-gap)/(column-width + column-gap))))
(11)  W := max(0, ((U + column-gap)/N - column-gap))

What is important to understand there is that the column-width can either be a floor or a ceiling, depending on the value of column-count.

Let’s take some examples.

/* Condition starting at line 3 applies */
body {
  column-width: auto;
  column-count: 2;
}

The column width is not set, it entirely depends on column-count and column-gap (which suggested default is 1em).

Columns theoretically have a floor (which is suggested to be 1px or less) and a ceiling (line 11).

/* Condition starting at line 5 applies */
body {
  column-width: 300px;
  column-count: auto;
}

In this example, the number of columns is computed depending on the column width and gap.

In other words, the column width is a ceiling: it can’t be larger than 300px but can shrink if the available width is less.

/* Condition starting at line 8 applies */
body {
  column-width: 300px;
  column-count: 2;
}

In this example, the column width is a floor: if 2 columns (2 × column width and the gap) can fit, column-count will be honored, else column-width grows to the width available. If there is additional width available when 2 columns fit, column-width will grow as well.

It’s worth noting that the used value for column-count is calculated without regard for explicit column breaks or constrained column heights, while the actual value takes these into consideration.

Stacking contexts

Column boxes do not establish new stacking contexts.

Column gaps and rules

What is important is that column gaps take up space while column rules don’t.

  1. column gaps will push apart content in adjacent columns (within the same multicol element);
  2. if there is a column rule between columns, it will appear in the middle of the gap.

As regards column rules:

Fragmentation (column break)

This has been moved to the CSS Fragmentation module.

When a page or column break splits a box, the box’s margins, borders, and paddings have no visual effect where the split occurs. It is important to remark outline and box-shadow are not discussed at all in the spec.

In the previous spec, it was stated that “the margin immediately after a forced page or column break will be preserved” but that isn’t necessarily the case in practice, CSS authors often having to resolve to padding-top to force a margin after a page break.

From experience, avoiding a break-inside elements flowing in 2 or 3 columns can also be problematic (the element vertical alignment is completely off).

Column span

You can only span all columns or none. It is not possible to declare an <integer>.

An element establishes a new block formatting context if its column-span is set to all. In other words, column-span kind of resets the flow to the first column.

We may not necessarily worry about this (in authors’ CSS) because the User Agent can treat it as column-span: none if it can’t find room to make the element spanning. Constraining the height of columns should be enough to prevent a column span, especially with overflow.

Filling columns

By default, columns will be balanced (minimal variation in column length), they won’t be filled sequentially.

This default can be overridden with

body {
  column-fill: auto;
}

It’s worth noting User Agents should try to honor widows and orphans in any case.

Overflow

What is important to remark is that:

Reflow

CSS multicol relies on a complex (fragmentation) logic, and this logic varies for each browser.

In Blink and Webkit for instance, a reflow won’t happen for the document (:root) if we don’t force a reflow at the body level. As a consequence, we’re using the --RS__maxLineLength CSS variable to force this reflow and slightly alter its value whenever needed e.g. “pagination to scroll” in vertical writing, mix-blend-mode in sepia mode, “number of columns” user setting, etc.

This will recalc the body’s max-width, causing a reflow which will propagate to the column layout we set for :root.

Notorious limitations

When the spec was published, the Financial Times immediately switched to its own JavaScript implementation for the following reasons:

As far as we can tell, this implementation might create some issues, especially when it comes to a11y because it duplicates and hides part of elements to manage fragmentation.

Notes

It is our understanding the Opera implementation of overflow: -o-paged-x in Presto solved most of the spec’s limitations, as listed by the Financial Times:

It is important to note the spec has been republished as a Working Draft. It is very unlikely a level 2 spec will tackle those problems in the short term.

From experience, we can also report there tends to be implementation-specific bugs with newer layout specs e.g. flexbox, grid, etc.

Missing pieces

There are several shortcomings we must deal with: