[csswg-drafts] Fixed column width mode for multi-column layout (#13665)

berlysia has just created a new issue for https://github.com/w3c/csswg-drafts:

== Fixed column width mode for multi-column layout ==
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:

```css
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|
|----|----|
|<img width="734" height="381" alt="Image" src="https://github.com/user-attachments/assets/15b9c75e-1786-4a0d-8787-abe704271595" />|<img width="786" height="292" alt="Image" src="https://github.com/user-attachments/assets/db90efaf-6ab1-4b93-91a0-bd7cc44103a8" />|

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|
|----|----|
|<img width="312" height="444" alt="Image" src="https://github.com/user-attachments/assets/49c4ac74-b048-4cdc-a03b-693dd2a3770d" />|<img width="396" height="530" alt="Image" src="https://github.com/user-attachments/assets/1bd7fe87-1d5f-4b94-8128-0dabd815ec82" />|

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 apply
* `column-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 prior discussion

- CSS Multi-column Layout Level 1 / 2
  - `column-width` as an ideal/optimal width
  - pseudo-algorithm using `U`
  - note that the multicol spec does not define how `U` is calculated
- CSS Writing Modes Level 4 ยง7.3.2
  - auto-sizing block containers in orthogonal flows
- Issue #9103
- Issue #1742
- Issue #4952
  

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13665 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 16 March 2026 20:41:08 UTC