{"id":389636,"date":"2025-10-13T08:31:35","date_gmt":"2025-10-13T14:31:35","guid":{"rendered":"https:\/\/css-tricks.com\/?p=389636"},"modified":"2025-12-08T08:19:31","modified_gmt":"2025-12-08T15:19:31","slug":"masonry-watching-a-css-feature-evolve","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/masonry-watching-a-css-feature-evolve\/","title":{"rendered":"Masonry: Watching a CSS Feature Evolve"},"content":{"rendered":"\n

You\u2019ve probably heard the buzz about CSS Masonry<\/a>. You might even be current on the ongoing debate about how it should be built, with two big proposals on the table, one from the Chrome team and one from the WebKit team.<\/p>\n\n\n\n

The two competing proposals are interesting in their own right. Chrome posted about its implementation<\/a> a while back, and WebKit followed it up with a detailed post<\/a> stating their position (which evolved out of a third proposal<\/a> from the Technical Architecture Group).<\/p>\n\n\n\n

We\u2019ll rehash some of that in this post, but even more interesting to me is that this entire process is an excellent illustration of how the CSS Working Group (CSSWG), browsers, and developers coalesce around standards for CSS features. There are tons of considerations that go into a feature, like technical implementations and backwards compatibility. But it can be a bit political, too.<\/p>\n\n\n\n\n\n\n\n

That\u2019s really what I want to do here: look at the CSS Masonry discussions and what they can teach us about the development of new CSS features. What is the CSSWG\u2019s role? What influence do browsers have? What can learn from the way past features evolved?<\/p>\n\n\n

Masonry Recap<\/h3>\n\n\n

A masonry layout is different than, say Flexbox and Grid, stacking unevenly-sized items along a single track that automatically wraps into multiple rows or columns, depending on the direction. It\u2019s called the \u201cPinterest layout\u201d for the obvious reason that it\u2019s the hallmark of Pinterest’s feed.<\/p>\n\n\n\n

\"Screenshot
Pinterest\u2019s masonry layout<\/figcaption><\/figure>\n\n\n\n

We could go deeper here, but talking specifically about CSS Masonry isn\u2019t the point. When Masonry entered CSS Working Group discussions, the first prototype actually came from Firefox back in 2019, based on an early draft that integrated masonry behavior directly into Grid.<\/p>\n\n\n\n

The Chrome team followed later with a new display: masonry<\/code> value, treating it as a distinct layout model. They argued that masonry is a different enough layout from Flexbox and Grid to deserve its own display<\/code> value. Grid\u2019s defaults don\u2019t line up with how masonry works, so why force developers to learn a bunch of extra Grid syntax? Chrome pushed ahead with this idea and prototyped it in Chrome 140<\/a>:<\/p>\n\n\n\n

.container {\n  display: masonry;\n  grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));\n  gap: 10px;\n}<\/code><\/pre>\n\n\n\n
Meanwhile, the WebKit team has proposed that masonry should be a subset of Grid, rather than its own display<\/code> type. They endorsed a newer direction<\/a> based on a recommendation by the W3C Technical Architecture Group (TAG) built around a concept called Item Flow<\/strong> that unifies flex-flow<\/code> and grid-auto-flow<\/code> into a single set of properties. Instead of writing display: masonry<\/code>, you\u2019d stick with display: grid<\/code> and use a new item-flow<\/code> shorthand to collapse rows or columns into a masonry-style layout:<\/p>\n\n\n\n
.container {\n  display: grid;\n  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));\n  item-flow: row collapse;  \n  gap: 1rem;\n}<\/code><\/pre>\n\n\n\n
The debate here really comes down to mental models and how you think about masonry. WebKit sees it as a natural extension of Grid, not a brand-new system. Their thinking is that developers shouldn\u2019t need to learn an entirely new model when most of it already exists in Grid. With item-flow<\/code>, you\u2019re not telling the browser \u201cthis is a whole new layout system,\u201d you\u2019re more or less adjusting the way elements flow in a particular context.<\/p>\n\n\n
How CSS Features Evolve<\/h3>\n\n\n
This sort of horse-trading isn\u2019t new. Both Flexbox and Grid went through years of competing drafts before becoming the specs we use today. Flexbox, in particular, had a rocky rollout in the early 2010s. Those who were in the trenches at the time likely remember multiple conflicting syntaxes floating around at once<\/a>. The initial release had missing gaps and browsers implemented the features differently, leading to all kinds of things, like proprietary properties, experimental releases, and different naming conventions that made the learning curve rather steep, and even Frankenstein-like usage in some cases<\/a> to get the most browser support.<\/p>\n\n\n\n
In other words, Flexbox (nor Grid, for that matter) did not enjoyed a seamless release, but we\u2019ve gotten to a place where the browsers implementations are interoperable with one another. That\u2019s a big deal for developers like us who often juggle inconsistent support for various features. Heck, Rob O\u2019Leary recently published the rabbit hole he traveled<\/a> trying to use text-wrap: pretty<\/code><\/a> in his work, and that\u2019s considered \u201cBaseline\u201d support that is \u201cwidely available.\u201d<\/p>\n\n\n\n
But I digress. It\u2019s worth noting that Flexbox faced unique challenges early on, and masonry has benefitted from those lessons learned. I reached out to CSSWG member Tab Atkins<\/a>-Bittner<\/a> for a little context since they were heavily involved in editing the Flexbox specification<\/a>.<\/p>\n\n\n\n
\n
\u201cFlexbox 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.\u201d<\/p>\n<\/blockquote>\n\n\n\n
In other words, Flexbox was sort of a canary in the coal mine as the CSSWG considered what a modern CSS layout syntax should accomplish. This greatly benefited the work put into defining CSS Grid because a lot of the foundation for things like tracks, intrinsic sizing, and proportions were already tackled. Atkins-Bittner goes on further to explain that the Grid specification process also forced the CSSWG to rethink several of Flexbox\u2019s design choices in the process.<\/p>\n\n\n\n
\n
\u201cWe 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.\u201d<\/p>\n<\/blockquote>\n\n\n\n
This also explains why Flexbox underwent several revisions<\/a> following its initial release.<\/p>\n\n\n\n
It also highlights another key point: CSS features are<\/strong> always<\/strong> evolving<\/strong>. Early debate and iteration are essential because they reduce the need for big breaking changes. Still, some of the Flexbox mistakes (which do happen<\/a>) became widely adopted. Browsers had widely implemented their approaches and the specification caught up to it while trying to establish a consistent language that helps both user agents and developers implemented and use the features, respectively.<\/p>\n\n\n\n
All this to say: Masonry is in a much better spot than Flexbox was at its inception. It benefits from the 15+ years that the CSSWG, browsers, and developers contributed to Flexbox and Grid over that time. The discussions are now less about fixing under-specified details and more about high-level design choices. Hence, novel ideas born from Masonry that combine the features of Flexbox and Grid into the new Item Flow proposal.<\/p>\n\n\n\n
It\u2019s messy. And weird. But it\u2019s how things get done.<\/p>\n\n\n
The CSSWG\u2019s Role<\/h3>\n\n\n
Getting to this point requires process. And in CSS, that process runs through the Working Group. The CSS Working Group (CSSWG) runs on consensus: members debate in the open, weigh pros and cons, and push browsers towards common ground.<\/p>\n\n\n\n
Miriam Suzanne<\/a>, an invited expert with the CSSWG (and CSS-Tricks alumni<\/a>), describes the process like this:<\/p>\n\n\n\n
\n
\u201cThe group runs on a consensus model, so everyone has to eventually come to an agreement \u2014 or at least agree not to block the most popular path forward.\u201d<\/p>\n<\/blockquote>\n\n\n\n
But consensus only applies to the specifications.<\/strong> Browsers still decide when and how to those features are shipped, as Suzanne continues:<\/p>\n\n\n\n
\n
\u201cBrowsers make their own decisions about how strictly they follow a spec, and sometimes release features that haven\u2019t been fully specified. That can lead to situations where the group decides to change a spec years later to match what browsers actually implemented.\u201d<\/p>\n<\/blockquote>\n\n\n\n
So, while the CSSWG facilitates discussions around features, it can\u2019t actually stop browsers from shipping those features, let alone how they\u2019re implemented. It\u2019s a consensus-driven system, but consensus is only about publishing a specification. In practice, momentum can shift if one vendor is the first to ship or prototype a feature.<\/p>\n\n\n\n
In most cases, though, the specification adoption process results in a stronger proposal overall. By the time features ship, the idea is that they\u2019ve already been thoroughly debated, which in theory, reduces the need for significant revisions later that could lead to breaking changes. Backwards compatibility is always at the forefront of CSSWG discussions.<\/p>\n\n\n\n
Developer feedback also plays an important role, though there isn\u2019t a single standardized way that it is solicited, collected, or used. For the CSSWG, the csswg-drafts GitHub repo<\/a> is the primary source of feedback and discussion, while browsers also run their own surveys and gather input through various other channels such as Chrome\u2019s technical discussion groups<\/a> and Webkit\u2019s mailing lists<\/a>.<\/p>\n\n\n
The Bigger Picture<\/h3>\n\n\n
Browsers are in the business of shaping new features. It\u2019s also in their best interest for a number of reasons. Proposing new ideas gives them a seat at the table. Prototyping new features gets developers excited and helps further refine edge cases. Implementing new features (particularly first) gives them a competitive edge in the consumer market.<\/p>\n\n\n\n
All that said, prototyping features ahead of consensus is a bit of a tightrope walk.<\/p>\n\n\n\n
And that\u2019s where Masonry comes back into the bigger picture. Chrome shipped a prototype of the feature that leans heavily into the first proposal for a new display: masonry<\/code> value. Other browsers have yet to ship competing prototypes, but have openly discussed their positions, as WebKit did in subsequent blog posts<\/a>.<\/p>\n\n\n\n
At first glance, that might suggest that Chrome is taking a heavy-handed approach to tip the scales in its favorable direction. But there\u2019s a lot to like about prototyping features because it\u2019s proof in the pudding for real-world uses by allowing developers early access to experiment.<\/p>\n\n\n\n
Atkins-Bittner explains it nicely:<\/p>\n\n\n\n
\n
\u201cPrototyping 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).\u201d<\/p>\n<\/blockquote>\n\n\n\n
This kind of \u201csoft\u201d commit moves conversations forward while leaving room to change course, if needed, based on real-world use.<\/p>\n\n\n\n
But there\u2019s obviously a tension here as well. Browsers may be custodians of web standards and features, but they\u2019re still employed by massive companies that are selling a product at the end of the day. It\u2019s easy to get cynical. And political.<\/p>\n\n\n\n
In theory, though, allowing browsers to voluntarily adopt features gives everyone choice: browsers compete in the market based on what they implement, developers gain new features that push the web further, and everyone gets to choose the browser that best fits their browsing needs.<\/p>\n\n\n\n
If one company controls access to a huge share of users, however, those choices feel less accessible. Standards often get shaped just as much by market power as by technical merit.<\/p>\n\n\n
Where We\u2019re At<\/h3>\n\n\n
At the end of the day, standards get shaped by a mix of politics, technical trade-offs, and developer feedback. Consensus is messy, and it\u2019s rarely about one side \u201cwinning.\u201d With masonry, it might look like Google got its way, but in reality the outcome reflects input from both proposals, plus ideas from the wider community.<\/p>\n\n\n\n
As of this writing:<\/p>\n\n\n\n