CSSWG Reopens the Five-Year Masonry Debate

The CSS Working Group's December 4th teleconference was dedicated to settling a question that has divided the group since 2020: should masonry layouts be implemented as part of the CSS Grid specification, or as a separate display type? The meeting featured formal presentations from both camps, input from the W3C Technical Architecture Group (TAG), and a straw poll that left the group without a consensus.

The underlying technical concerns about grid-integrated masonry have largely been resolved. The remaining disagreement centers on syntax — specifically, which approach is easier for authors to learn, and how each choice might constrain future CSS development.

The Case for a Separate display: masonry

Alison Maher of Microsoft, advocating for masonry as a new display value, opened with a presentation arguing that grid and masonry have fundamental behavioral differences that make integration problematic. Her key points:

  • Several properties behave differently between masonry and grid, including placement and alignment.
  • A dedicated display: masonry enables better defaults; the grid-integrated fallback argument is weak because "needing one is a temporary problem, so [we] should focus on the future."
  • Positioning in masonry is simpler — it operates along one axis rather than two.
  • Masonry shorthand would be simpler than grid shorthand, avoiding the need to remember property order.
  • Future work on submasonry/subgrid will introduce further divergences.
  • Integrating masonry into grid leads to spec bloat, creates teaching difficulties, and risks developer confusion.

alisonmaher: "Conclusion: masonry should be a separate display type"

The "Just Use Grid" Counterproposal

Jen Simmons of WebKit followed with the opposing view. Her presentation argued that a separate masonry layout type would create unnecessary fragmentation in CSS:

  • A new layout type creates "a separate tool with separate syntax that's similar but not the same as what exists — they're familiar but not quite the same," complicating the learning curve for authors.
  • The Chrome proposal would add roughly ten new properties to CSS, a cost the WebKit team doesn't believe is justified.
Table of properties that display: masonry would add. (around 10 new properties)
  • The existing grid-auto-flow property already handles the auto-flow behavior that the masonry proposal redefines.
  • Grid template syntax for rows can be reused directly; the new masonry proposal changes this syntax for rows, creating inconsistency.
  • The new display type's claimed better defaults don't hold up in practice, often requiring deep understanding of autosizing.
  • Using grid for masonry eases switching at breakpoints and supports progressive enhancement.
  • Reusing existing CSS mechanisms follows established design principles.
Difference in template syntax between Just use Grid vs display: masonry

TAG Review Weighs In

Lea Verou, also a TAG member, presented the TAG's review of the issue. The TAG found WebKit's arguments compelling and recommended going further than a simple grid integration:

lea: A lot of arguments for integrating [masonry into grid] is that "grid is too hard". In that case we should make grid things easier. Complex things are possible, but simple things are not so easy.

The TAG argued that masonry use cases often need simpler grids, which points toward making grid definitions easier overall rather than introducing a parallel system. Adding many new properties increases the API surface authors must learn, and the TAG noted a practical concern: "Even if we say we will be disciplined, experience shows that we won't." The review also observed that grid layouts were historically often one-dimensional in graphic design, undermining the argument that masonry doesn't belong in a 2D grid model.

The TAG suggested exploring a shorthand that could set grid-auto-flow and flex-direction together, giving authors a single control for layout direction across different modes.

Open Debate and Divergent Views

The presentations were followed by discussion among working group members, during which fundamental disagreements about design philosophy surfaced.

Oriol Brufau challenged a key WebKit argument, noting that the proposed masonry-direction property actually aligns with flex-direction rather than grid-auto-flow. He argued that consistency with flexbox is a legitimate design choice.

Alan Stearns said he had changed his position after hearing the TAG argument: "I thought that separate display property made a lot more sense... but the TAG argument convinced me that we should do the work of integrating these things."

Tab Atkins responded by directly rebutting the TAG position:

TabAtkins: You can draw a lot of surface-level connections between Grid and Masonry, and Flexbox, and other hypothetical layouts but when you actually look at details of how they work, behaviors each one is capable of, they're pretty distinct if you try to combine together, it would be an unholy mess of conflicting constraints.

Lea countered that the TAG's position was that layout exists on a continuum, and syntax should reflect that rather than forcing designers into two extremes.

Jeffrey Yasskin suggested a potential middle ground: share properties between systems wherever possible, even if display values remain distinct. He specifically criticized the unified proposal's handling of grid-auto-flow, where "some values were ignored," calling this a significant usability problem.

Jen Simmons emphasized the simplicity of the grid approach: "To create a simple masonry-style layout in Grid, you just need 3 lines of code (4 with a gap)."

A Straw Poll With No Clear Winner

As discussions continued without a path forward, Lea proposed a straw poll to gauge how far the group was from consensus. The results were split, with no clear preference for either proposal. In the absence of consensus, no implementation can move forward.

Straw Poll for Just Use Grid, showing a split result. 12 NOs, 13 YES and 5 ABSTAIN

The working group members acknowledged the quality of both presentations — Florian Rivoal noted that the arguments were "clearly presented, densely packed, well delivered" — but the five-year debate remains unresolved. Both camps have dug in, and neither side shows signs of conceding. The outcome leaves the CSSWG in a familiar position: waiting for a proposal that meaningfully addresses concerns from both sides before masonry becomes a formal part of CSS layout.