Masonry’s Many Proposals
CSS Masonry—the “Pinterest layout” that packs unevenly sized items into tidy rows or columns—has been a hot topic in the frontend community, not least because the fight over its implementation is still very much ongoing. Two major proposals are on the table: one from the Chrome team advocating for a standalone display: masonry value, and another from WebKit that sees masonry as an extension of CSS Grid via a new unified concept called Item Flow.
The competing visions are more than just a technical disagreement. They are a case study in how new CSS features go from idea to specification, and how the CSS Working Group (CSSWG), browser vendors, and developers interact along the way. The first masonry prototype actually came from Firefox in 2019, working from an early draft that baked masonry directly into Grid. Chrome followed with its own prototype in Chrome 140, arguing that masonry is distinct enough from Grid to deserve its own display value, as Grid’s defaults don’t map cleanly onto masonry’s behavior:
.container {
display: masonry;
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
gap: 10px;
}WebKit’s counter-proposal, based on a recommendation from the W3C Technical Architecture Group (TAG), suggests keeping display: grid and introducing a new item-flow shorthand (which would unify flex-flow and grid-auto-flow) to collapse rows or columns into a masonry-style layout:
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
item-flow: row collapse;
gap: 1rem;
}At its core, the debate is about mental models. WebKit sees masonry as a natural extension of Grid, not a brand-new system. Developers shouldn’t need to learn an entirely new layout model when most of the machinery already exists in Grid. With item-flow, they argue, you’re not declaring a new layout type; you’re just adjusting the flow of items in a given context.
How CSS Features Actually Evolve
This kind of back-and-forth is not new. Both Flexbox and Grid went through years of competing drafts before becoming the specs we rely on today. Flexbox in particular had a choppy rollout in the early 2010s, with multiple conflicting syntaxes floating around, browsers implementing features differently, and developers resorting to proprietary properties and experimental releases. It was messy, but it was also a learning experience.
Tab Atkins-Bittner, a CSSWG member who helped edit the Flexbox specification, puts it plainly: “Flexbox was the first of the modern layout algorithms; we made a lot of mistakes and missteps while writing it, because we were trying to figure out how a modern layout model should work.” That legacy directly benefited CSS Grid, which built on foundations like tracks and intrinsic sizing that flexbox had already explored. But the Grid process also forced the CSSWG to revisit flexbox decisions, as Atkins-Bittner explains: “We found a lot of decisions that made sense on their own in Flexbox needed to be changed if we wanted them to apply more generally.”
That explains why flexbox went through several revisions following its initial release. Some of its mistakes, however, had already been widely adopted by browsers, and the specification had to catch up to established implementations rather than forcing breaking changes. The key takeaway is that CSS features are always evolving, and early, messy debate is what reduces the need for larger course corrections down the road.
Masonry is arguably in a much better position than Flexbox was at its inception. It benefits from more than a decade of collective work on Flexbox and Grid. The discussions today are less about fixing under-specified details and more about high-level design choices—which is why we’re seeing novel concepts like Item Flow that merge Flexbox and Grid ideas together. It’s odd and messy, but it’s how the process works.
The CSSWG’s Role in the Process
The CSSWG operates on a consensus model. Members debate publicly, weigh trade-offs, and strive toward a common position. Miriam Suzanne, an invited expert with the group, describes it this way: “The group runs on a consensus model, so everyone has to eventually come to an agreement—or at least agree not to block the most popular path forward.”
But consensus only applies to publishing specifications. Browsers make their own decisions on how strictly to follow those specs, and sometimes ship features that haven’t been fully vetted. As Suzanne notes, “Browsers make their own decisions about how strictly they follow a spec, and sometimes release features that haven’t been fully specified. That can lead to situations where the group decides to change a spec years later to match what browsers actually implemented.”
The CSSWG can’t stop a browser from shipping a feature, nor can it dictate how that feature is implemented. In practice, a vendor that prototypes or ships first can shift the momentum of the entire conversation. Still, thorough debate before ship tends to produce stronger proposals and reduces the likelihood of breaking changes later on.
Developer feedback is also part of the equation, though there’s no standardized pipeline for it. The csswg-drafts GitHub repo is the primary avenue for CSSWG discussion, while browsers run their own surveys and engagement channels, such as Chrome’s technical discussion groups and WebKit’s mailing lists.
The Politics of Prototyping
Browsers are businesses with a vested interest in shaping new features. Proposing ideas gives them a seat at the table; prototyping gets developers excited and helps refine edge cases; shipping first is a competitive advantage. Chrome’s prototype of display: masonry ahead of full consensus could be seen as a heavy-handed tactic, but it’s also a practical way to build agreement. As Atkins-Bittner puts it: “Prototyping before consensus is an important part of building consensus. You get early implementation feedback, you get more eyes on the problem (the implementing engineers rather than just the spec authors).”
That “soft” commitment keeps the conversation moving while leaving room for course correction based on real-world usage. There’s a tension, though: browsers are run by large companies selling products, so political and market pressures inevitably shape standards just as much as technical merit. If one vendor controls access to most users, the “choice” that a voluntary standards process promises can start to feel less meaningful.
Where Masonry Stands Now
Standards evolve through a mix of politics, trade-offs, and developer input—not because one side wins. With masonry, the outcome so far reflects elements of both proposals as well as wider community input. As of this writing:
- Masonry will become a new display type, with the keyword still being debated—but it must include the word “grid” in its name.
- The CSSWG has resolved to proceed with the proposed
item-flowapproach. - Grid will still be used for layout templates and explicit item placement.
- Some details, such as a possible shorthand syntax and track listing defaults, remain under discussion.
The process is far from clean, but that’s precisely what makes it effective. Between competing browser interests, years of hard-won layout experience, and the community’s evolving expectations for what the web should do, masonry’s path to standardization is a textbook example of how CSS grows up.
