Masonry: Observing the Evolution of a CSS Feature

You’ve likely heard the buzz about CSS Masonry. There’s an ongoing debate about its development, with proposals from both the Chrome and WebKit teams.

The proposals are intriguing. Chrome detailed its implementation earlier, and WebKit shared their stance, which evolved from a third proposal by the Technical Architecture Group.

This discussion highlights how the CSS Working Group (CSSWG), browsers, and developers collaborate on CSS standards. Many factors, like technical implementation and compatibility, play a role, and the process can be political.

Here, I aim to explore the CSS Masonry discussions and what they reveal about developing new CSS features. What role does the CSSWG play? How do browsers influence the process? What can we learn from past feature evolutions?

Masonry Recap

A masonry layout differs from Flexbox and Grid by stacking unevenly-sized items along a track that wraps into rows or columns. It’s often called the “Pinterest layout.”

When Masonry entered CSSWG discussions, Firefox first prototyped it in 2019, integrating masonry behavior into Grid.

The Chrome team later proposed a new display: masonry value, treating it as a distinct layout model. They argued for a separate display value, as Grid’s defaults don’t align with masonry. Chrome prototyped this in Chrome 140:

“`css
.container {
display: masonry;
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
gap: 10px;
}
“`

Meanwhile, WebKit proposed masonry as a subset of Grid, not a new display type. They endorsed a direction based on the W3C Technical Architecture Group’s Item Flow concept, unifying flex-flow and grid-auto-flow. Instead of display: masonry, you’d use display: grid and item-flow shorthand:

“`css
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
item-flow: row collapse;
gap: 1rem;
}
“`

The debate centers on mental models of masonry. WebKit sees it as a Grid extension, not a new system, so developers don’t need to learn a new model. With item-flow, you adjust element flow in context.

How CSS Features Evolve

This kind of negotiation isn’t new. Flexbox and Grid had years of drafts before becoming the specs we use. Flexbox faced challenges in the early 2010s with conflicting syntaxes and browser implementations, leading to proprietary properties and experimental releases.

Flexbox and Grid eventually reached interoperable implementations, benefiting developers dealing with inconsistent support. Flexbox faced unique challenges, and masonry has learned from those lessons. Tab Atkins-Bittner, a CSSWG member, notes that Flexbox was the first modern layout algorithm, with mistakes that informed CSS Grid’s development.

CSS features always evolve. Early debate and iteration reduce the need for breaking changes. Flexbox’s mistakes became widely adopted as browsers implemented their approaches, and the specification caught up.

Masonry is in a better position than Flexbox was. It benefits from years of CSSWG, browser, and developer contributions to Flexbox and Grid. Discussions focus on high-level design choices, leading to the new Item Flow proposal.

It’s messy and weird, but that’s how progress happens.

The CSSWG’s Role

Reaching this point requires process, which runs through the Working Group. The CSSWG operates on consensus: members debate openly, weigh pros and cons, and push browsers toward common ground.

Miriam Suzanne, a CSSWG expert, describes the process as consensus-driven, where everyone must agree or not block the popular path forward.

Consensus applies to specifications, but browsers decide when and how to ship features. Sometimes, browsers release features not fully specified, leading to changes in specs to match implementations.

The CSSWG facilitates feature discussions but can’t stop browsers from shipping features. Consensus is about publishing a specification, but momentum can shift if one vendor ships or prototypes first.

The specification adoption process results in stronger proposals. Features are thoroughly debated before shipping, reducing the need for revisions that cause breaking changes. Backwards compatibility is a priority.

Developer feedback is crucial, gathered through the csswg-drafts GitHub repo, browser surveys, and other channels like Chrome’s technical discussion groups and Webkit’s mailing lists.

The Bigger Picture

Browsers shape new features for various reasons. Proposing ideas gives them a seat at the table. Prototyping features excites developers and refines edge cases. Implementing features first gives a competitive edge.

Prototyping ahead of consensus is a tightrope walk.

Masonry exemplifies this. Chrome shipped a prototype for display: masonry. Other browsers haven’t shipped competing prototypes but have discussed their positions.

Chrome’s approach might seem heavy-handed, but prototyping proves real-world use, allowing developers early access to experiment.

Atkins-Bittner explains that prototyping before consensus builds consensus by providing early feedback and more problem-solving eyes.

Prototyping moves