Masonry Layout in CSS: the great debate

There’s a really interesting discussion going on at the moment about the best way to implement “masonry” layout in CSS. In the Apple corner is Jen Simmons, who’s written this really interesting article about why masonry layout should be a part of CSS Grid:

In the Google corner is Rachel Andrew, who has written a really compelling article about why masonry layout should be its own separate layout method (display: masonry or something like that):

I encourage you to read through these two arguments and see which you’re convinced by. After careful consideration, I’m siding with Rachel Andrew (even though I love the idea of grid-template-rows: masonry). But she really knows her stuff, and the issues she highlights over mixing Grid and masonry layout should give us pause.

There are also interesting debates on alternatives to the name masonry. You’ll find them in Jen’s article.

1 Like

Interesting discussion. Frankly I already have trouble understanding and remembering the grid layout mechanisms, and worry about it simply getting more and more complicated as things like masonry are added to it. But Rachel’s points about reusing existing components of grid are appealing, and may outweigh my “keep it simple” first thought. Either way it’s done, my main comments would be:

  • Make masonry as simple as possible, and not just more and more attributes within grid. Consider using sub-types like display:grid;style=columns; to pre-select a set of css grid properties that will get the developer 75% of the way there, while still leaving all of the underlying css properties and what-not available for more detailed layout.
  • My main attempt at using existing masonry JS tools in several sites has failed, largely because my images (<figure> elements, actually) are not all the same size, either in height or width, and I haven’t found a good solution to that. So I’ve written my own JS to take a list of <figures> and re-sort their display to fit them on the minimal screen area. I’m not sure I saw that use case in either of the proposals, but if it’s not there I (one small voice) would like to see it.

Yes, that’s the problem. Grid is already too complex for what you need most of the time.

I’m not a fan of masonry layouts anyway and it seems that its putting design ideas into the css rather than a set of tools that can create whatever you want.

It has been possible to do a basic masonry layout for years in plain css for most simple cases using a couple of lines in css columns.

What could be simpler than that :slight_smile:


Hah, yes, quite simple, although as pointed out in the article(s), that requires scrolling up and down the page if reading the content in source order. A lot of newspapers lay out items in a “masonry” config, and it’s not unreasonable to want to do the same in CSS, and maybe be able to have differently sized columns … although I’ve never needed to, admittedly. This is just one of many things it might be able to be nice to do in CSS, but as you say, writing CSS for specific layouts might not be the best approach. I guess the point of having it as an option in Grid is that Grid can do all sorts of things, but it is already getting a bit complicated, with lots of confusing dos and donts already!

1 Like

Yes I found that a rather incongruous statement because every demo they showed was a mish mash of images and text that had no logical flow anyway. Indeed some spanned items were stacked across columns and below previous items. Essentially there is no logical flow in a masonry layout which I though was the whole purpose of using it :slight_smile:

1 Like

I found this discussion off of one of Kevin Powell’s videos where he started discussing it. The frightening thing for me is if this schisms off like the 9 million (seemingly) ways to color something, or different sizing mechanisms. ugh!

I never understood why css columns were put in the way they were. There are “some” of the same properties available (at least according to MDN) but they seemed to be put in half-baked.

Or why when they put in Grid, they didn’t put in “display: columns” which would re-use grid and ignore the row attributes and get rid of the css columns implementation entirely.


Yes, it is a bit funny in that regard. The only real argument that gets mentioned is tabbing order, but as you say, the order get mixed up anyway in some of the demos.

I think there are 12 million ways now. Keep up!

Yes, one of the tensions is that “grid” means columns and rows, and that it just being about columns breaks the idea of “grid”.

It would make a lot of sense to upgrade the columns feature to be much more flexible. It’s okay (and nice and simple) but could do more.

1 Like