We need a mode where column-width specifies the actual used column width, rather than merely serving as an ideal width.
Proposal summary
Current multi-column layout first determines the available inline size and then divides that space into columns.
A fixed column width mode takes the opposite approach. It generates columns at an author-specified constant inline size and derives the container's inline-size from the resulting column layout.
This is not just a simple extension of the existing column-width. It introduces a different sizing model for multi-column layout.
Syntax
Not proposing a specific syntax here. As a rough sketch to aid discussion:
column-width: 300px fixed;
The point of this proposal is the sizing model, not the syntax.
What this enables
With fixed column width, multi-column layout can be treated as a mechanism for adding columns while maintaining a constant line length and column width, rather than a mechanism for dividing space first.
In this model, it becomes natural to implement a UI where the next column slightly peeks out from the scroll area to hint at more content. This is a common pattern in card UIs or carousels, and it should be equally natural in multi-column layout.
| Current behavior |
This proposal |
 |
 |
This also makes multicol a more practical option for integrating vertical writing into the vertically scrolling web.
| This proposal |
Patterns made possible by this proposal |
 |
 |
A practical limitation of current multicol is that additional columns appear as overflow columns, while the multicol container itself does not naturally extend to include them. This makes it hard to place trailing content such as a footer, end marker, or post-reading UI after the column sequence in normal flow.
A fixed column width mode would make that kind of trailing content placement much more natural.
Current workarounds
As an author-side workaround, one can approximate fixed-column-width behavior by fixing inline-size to match column-width and recalculating dimensions with JavaScript.
However, this merely shifts container sizing into author code, even though it should be handled by the layout engine.
Suggested starting points for requirements
These are not hard requirements but suggested constraints to scope initial discussion:
column-count may be auto or a specified <integer>column-width must be a <length>column-fill: balance must not applycolumn-span: all must not apply
Allowing % from the outset would require defining a reference for percentage resolution, which would complicate a mode where the container size is itself derived from layout. This is the same class of circular dependency discussed in #3095 for orthogonal flows.
Related topics
Orthogonal Flows
The fixed column width mode is not a proposal specifically for orthogonal flows.
However, it fits well with the circular reference problem around U (the used inline size of the multi-column container) that current multicol faces in auto-sized orthogonal flows.
By making each column's inline-size author-defined up front, this mode removes the need to derive column width from the same sizing process.
Intrinsic Sizing for Multi-column Layout
Issue #9103 discusses the max-content width of a multicol container with only column-width specified. As dholbert put it:
"The multicol element's content-width should be essentially determined by the column-width and number-of-columns."
In fixed column width mode, we can at least decouple the determination of each column's width from content measurement.
The central remaining problem is then determining how many columns are needed as a result of fragmentation. Since this is affected by forced breaks and orphans / widows, layout is still necessary. However, that layout is needed not to assume U first, but to determine the resulting column count.
Background specs and related discussion
We need a mode where
column-widthspecifies the actual used column width, rather than merely serving as an ideal width.Proposal summary
Current multi-column layout first determines the available inline size and then divides that space into columns.
A fixed column width mode takes the opposite approach. It generates columns at an author-specified constant inline size and derives the container's
inline-sizefrom the resulting column layout.This is not just a simple extension of the existing
column-width. It introduces a different sizing model for multi-column layout.Syntax
Not proposing a specific syntax here. As a rough sketch to aid discussion:
The point of this proposal is the sizing model, not the syntax.
What this enables
With fixed column width, multi-column layout can be treated as a mechanism for adding columns while maintaining a constant line length and column width, rather than a mechanism for dividing space first.
In this model, it becomes natural to implement a UI where the next column slightly peeks out from the scroll area to hint at more content. This is a common pattern in card UIs or carousels, and it should be equally natural in multi-column layout.
This also makes multicol a more practical option for integrating vertical writing into the vertically scrolling web.
A practical limitation of current multicol is that additional columns appear as overflow columns, while the multicol container itself does not naturally extend to include them. This makes it hard to place trailing content such as a footer, end marker, or post-reading UI after the column sequence in normal flow.
A fixed column width mode would make that kind of trailing content placement much more natural.
Current workarounds
As an author-side workaround, one can approximate fixed-column-width behavior by fixing
inline-sizeto matchcolumn-widthand recalculating dimensions with JavaScript.However, this merely shifts container sizing into author code, even though it should be handled by the layout engine.
Suggested starting points for requirements
These are not hard requirements but suggested constraints to scope initial discussion:
column-countmay beautoor a specified<integer>column-widthmust be a<length>column-fill: balancemust not applycolumn-span: allmust not applyAllowing
%from the outset would require defining a reference for percentage resolution, which would complicate a mode where the container size is itself derived from layout. This is the same class of circular dependency discussed in #3095 for orthogonal flows.Related topics
Orthogonal Flows
The fixed column width mode is not a proposal specifically for orthogonal flows.
However, it fits well with the circular reference problem around
U(the used inline size of the multi-column container) that current multicol faces in auto-sized orthogonal flows.By making each column's
inline-sizeauthor-defined up front, this mode removes the need to derive column width from the same sizing process.Intrinsic Sizing for Multi-column Layout
Issue #9103 discusses the
max-contentwidth of a multicol container with onlycolumn-widthspecified. As dholbert put it:In fixed column width mode, we can at least decouple the determination of each column's width from content measurement.
The central remaining problem is then determining how many columns are needed as a result of fragmentation. Since this is affected by forced breaks and
orphans/widows, layout is still necessary. However, that layout is needed not to assumeUfirst, but to determine the resulting column count.Background specs and related discussion
column-widthas an ideal/optimal widthUUis calculated