Re: [csswg-drafts] [css-grid-3][masonry] item-flow row vs. column in masonry layouts (#12803)

> With masonry, flowing the items horizontally from one column to the next creates a strong vertical visual effect after you remove the vertical spaces between items of dissimilar heights. But that is the visual effect of flowing the items in horizontal order. The actual orderly placement of the items is due to a horizontal flow of items, just as it is in row-based flexbox or a grid with a column template. Just as it is when adding characters to a line box. That is what most of us, I think, would consider the "flow" of content. Whether I rotate the box 90 degrees, or remove vertical spaces from between grid items, it doesn't change the fact that first I flowed it horizontally.
> 
> The final visual effect of having strong vertical alignments is why you use masonry, but it doesn't change the fact that you start by flowing items into rows first. If you use "column" as the value to do that, I would expect something like multicol. It would be contrary to how the word works everywhere else, and would be supremely confusing. I would hate that. You'd need tutorials to explain why it doesn't follow the same logic as how things flow elsewhere.

I disagree with this point of view because of how you described masonry to work. A waterfall masonry does **not** first flow items into rows, across the layout's various columns, to then remove the empty space and end up with something that's tightly packed.

Instead, the algorithm is opportunistic and depends, at each step, on the current total accumulated heights of the items in each column. The next item is placed entirely depending on which column is shortest at that particular moment.
Because of this, you may very well never flow items in horizontal order at all. Imagine a 3 columns masonry layout with two extremely tall items. Because they occupy so much space, the remaining (shorter) items would all go into the 3rd column until its height exceeds one of the other columns. If you first flowed items in rows, you'd end up with an entirely different layout.

Consider this visual grid (left) vs. masonry (right) comparison:

<img width="1359" height="1076" alt="Image" src="https://github.com/user-attachments/assets/651abf0a-03e5-4fb4-9271-b3711c90003a" />

Removing the empty space in the grid example on the left doesn't create the masonry example on the right.
But also, try to follow the items one by one in the masonry example, by using their numbers. Can you spot a horizontal row pattern as you do so?

The flow of items in masonry is really hard to see, and sometimes looks chaotic, because the algorithm that packs items is opportunistic. That's why masonry is usually best for image galleries, portfolios, and other cases where the final visual arrangement is more important than the reading order.

My opinion is that masonry is different from grid in that it _doesn't let you choose the flow of items_ in the same way. It only lets you choose:

1. The shape of the lanes: columns, rows (and how wide they are).

2. The starting edge of the layout: top or bottom for columns, and left or right for rows.

   Example: in a waterfall masonry layout, do items start to pack at the top, or at the bottom?

3. The author's preference for which lane wins in case of ties: left or right for columns, and top or bottom for rows.

   Example: in a waterfall masonry layout, if two columns are tied for shortest height, which one gets the next item?

I think that's a pretty fundamental aspect of masonry: you don't really get to choose the flow of items, only the general shape of the layout and starting edge + tie winning side.

Because of this, to me, masonry feels much closer to flexbox than it does to grid. I'm still of the opinion that `grid-auto-flow` is not the right choice, and that something that mimics flexbox's `flex-direction` is the right way to go (i.e. `grid-lanes-direction`).

But, as @alisonmaher [mentioned](https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3760855940), getting broader developer feedback would probably allow to make more progress here.
Happy to help set that up. Alison and I have been working on some early content ideas which can be discussed at the next meeting.

-- 
GitHub Notification of comment by captainbrosset
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3769085386 using your GitHub account


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

Received on Monday, 19 January 2026 16:01:00 UTC