Re: [csswg-drafts] [css-grid-3] Masonry Switch Syntax (#12022)

After analyzing all recent inputs on the syntax switch thus far, my opinion remains unchanged that `display` makes the most sense as the trigger. 
 
**Re: `display` as the trigger** 
 
Firstly, let’s start by looking at the definition of a `display` type. According to [css-display-3,](https://www.w3.org/TR/css-display-3/#the-display-properties)  a `display` type “defines...the kind of [formatting context](https://www.w3.org/TR/css-display-3/#formatting-context) it generates, dictating how its descendant boxes are laid out.” In other words, a display type defines the way in which sizing and positioning happens for its children. 

In Grid, we place items then size the tracks. Masonry is the opposite and has a very different placement algorithm than Grid. Masonry also introduces differences in track sizing, new rules for dense packing and fit-content, differences in how subgrid works, differences in alignment, etc. 
 
Although there are overlaps between Grid and Masonry, they each size and place items differently, which under the definition of display type, means these are distinct modes. As such, reusing `display` as the trigger for masonry reuses an existing property for its intended purpose. 

Moreover, the long list of differences, including differences in the set of properties that are valid or mean different things in each layout mode leads me to believe we will continue to come across extensions of either that don’t make sense in the other, which would be limiting if grouped under the same display type (such as [how `repeat(auto-fill, auto)` could work in each](https://github.com/w3c/csswg-drafts/issues/9321)). 
 
A [post](https://www.miragecraft.com/blog/css-masonry-syntax-should-be-grid-independent) on the miragecraft blog summarizes this point quite well - “However if we do discover a use case for a potential masonry feature that is impossible to implement when integrated into the grid, that would be a much bigger problem to deal with.” 

And lastly, a [post](https://keithjgrant.com/posts/2024/05/weighing-in-on-css-masonry/) by Keith Grant provides an insight into the teachability of using `display:masonry` over integrating masonry into grid. “If masonry is a part of grid, the way to teach masonry becomes: 'go learn grid at a deeper level.' Then, upon learning more about grid, the next step becomes: “half of what you just learned about grid does not apply to masonry…. I think it’s far more approachable to teach display: masonry…Then, at the end of that lesson, you can say, 'and the good news is, most of what you just learned applies to grid as well!'"
 
**Re: `item-flow` as the trigger** 
 
Webkit’s [most recent blog](https://webkit.org/blog/17219/item-flow-part-2-next-steps-for-masonry/) surrounding using `item-flow` as the trigger actually explains the need for a new `display` type (unintentionally) quite well -  the blog note that Grid’s “layout mode” is in the form of rows and columns, creating a layout mode of strictly aligned cells. Flexbox’s “layout mode” is that of distinct rows or columns in one axis, and masonry’s “layout mode” being “strict columns and messy rows…while the rows are inconsistent and broken up”. 
 
Per the examples in the blog, masonry’s “layout mode” actually more similarly matches that of Flexbox. What the blogpost calls “messy rows” are not rows at all, and although masonry shares similar track terminology and functionality to grid in one direction, masonry does not create the same kind of “layout mode” where distinct rows/columns are formed into a cell-like format. The way we distinguish different layout modes today is through `display`.
 
Furthermore, simplifying the differences between Masonry and Grid to how items flow within a Grid is not painting the full picture. For other kinds of item flow values, the core “layout mode” remains unchanged. In Masonry, switching the item flow of the container not only changes how the items flow, but the container no longer has distinct cells (rows and columns). As such, we need a way to trigger masonry that captures all of these differences. 
 
**Re: `grid-template-columns/rows: masonry` as the trigger** 
 
When writing tests, I personally found the syntax of setting `masonry` on either the template row/column direction to force me to think deeply about what direction I was applying to the stacking axis. A [post](https://www.moon-odyssey.com/en/css-masonry/) on River’s Blog summarizes this point well - “using grid-template-columns/grid-template-rows with masonry goes against my intuition. Simply put, to achieve a vertical waterfall flow, you need to use grid-template-rows: masonry, while I instinctively thought it would be grid-template-columns.” 
 
I found that setting `masonry-direction` to define the stacking axis, and grid-template properties to define the grid direction to be much more self-explanatory, easier to remember, and easier to reason about. 

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


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

Received on Monday, 18 August 2025 12:42:02 UTC