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

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

== [css-grid-3][masonry] item-flow row vs. column in masonry layouts ==
Following up on the adoption of `item-flow` in [#11480 Unifying grid-auto-flow and flex-flow](https://github.com/w3c/csswg-drafts/issues/11480) (see [this WebKit blog post](https://webkit.org/blog/16587/item-flow-part-1-a-new-unified-concept-for-layout/) for an overview of `item-flow` if you want a refresher), one of the key questions was about the interpretation of its `row` and `column` values for masonry layout.

The core of this question is about whether the `row` and `column` values of `item-flow` represent the “shape” of the layout or the “flow” of the layout. In Flexbox, these two concepts coincide; and in Grid, the “shape of layout” is ambiguous while the keywords indicate the “flow” of the layout, so there's no conflict. But in masonry layout, they are opposite concepts. See [this illustrated explanation](https://webkit.org/blog/17219/item-flow-part-2-next-steps-for-masonry/#:~:text=Issue%20#2:%20What%E2%80%99s%20a%20row,%20anyway?) of these concepts and how they apply to flex/grid/masonry.

This brings us to some concrete questions about the proposed CSS syntax for `item-flow`:

**Question 1:** For defining a masonry layout's orientation, should we:
* Use `item-flow: column` to represent waterfall layouts and `item-flow: row` to represent brick-wall layouts?
    * This would follow the “shape of layout” interpretation for these keywords, which is likely more obvious to most people at first glance.
     * In this case the initial value would differ between grid/flex (`row`) and masonry (`column`).
     * Switching a grid/flex layout to a similarly-flowing masonry layout or vice versa would mean inverting the `item-flow` value.
* Use `item-flow: row` to represent waterfall layouts and `item-flow: column` to represent brick-wall layouts?
    * This would follow the "flow of layout" interpretation for these keywords.
    * It creates a consistent "flow of layout" interpretation across grid/flex/masonry layouts, so switching between layout types (grid/flex/masonry) would maintain the overall direction of flow for a given value of `item-flow`.
    * But it breaks the expectation that `row` creates a visible “row” in the layout.
* Use `item-flow: inline` to represent waterfall layouts and `item-flow: block` to represent brick-wall layouts?
    * This would keep consistent a "flow of layout" interpretation across all three layout modes, while side-stepping the “shape of layout” expectation.
    * But the resulting keywords are inconsistent with the existing `flex-flow` and `grid-auto-flow` properties.
* Something else?

**Question 2:** If we go with the second or third approach, the `item-flow` longhands are very obviously `item-direction` and `item-wrap`, consistent with (and mapping directly to) `flex-flow` and `grid-auto-flow`. But if we go with the first approach (“shape of layout”):
 * Does `item-direction: row | column | row-reverse | column-reverse`  and `item-wrap: wrap | wrap-reverse` still make sense?
 * What does `item-direction: row-reverse` or `item-wrap: wrap-reverse` mean in this case, i.e. which one reverses what?
 * Do we need different names for these properties so that they make sense when shared across grid/flex and masonry? E.g. `item-track` and `item-cross` were proposed as a possibility. If so, is this inconsistency with the existing `flex-flow` longhands an acceptable cost?

Note that regardless, the default masonry layout will be a “waterfall” layout, i.e. the declared grid tracks are columns, and items are placed across and then down, so it's really only in the case of “brick-wall” layouts that a keyword would need to be specified.

There's some existing discussion on these questions in the [previous issue](https://github.com/w3c/csswg-drafts/issues/11480) but I wanted to pull out these questions to get thoughts from people other than me and Tab, particularly from our Invited Experts, others working as CSS authors and educators, and from people outside the CSSWG.




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


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

Received on Monday, 15 September 2025 21:57:59 UTC