I’ll repoint to my feeling that reading-order is very related and also opens possibility in that we can use what we’ve already got in broader ways without negative accessibility implications.

The CSS Working Group has combined the two CSS masonry proposals into one draft specification. The group hopes that this will make it easier to compare the two, and make a final decision. The Chrome team still believes that a separate masonry syntax would be the best way to proceed.

I admit I find it a bit brain-bending and mostly don’t care which way it goes. Both Geoff and Miriam have fantastic overviews and also both stop short of a strong opinion either way. To keep it spicy, I have a slight preference for keeping it in grid, as adding four new properties for this relatively niche layout need feels like a bit much, even if it does complicate grid by existing. Rachels feels strongly the other way.

Then: nothing. Web standards just move at the pace that it moves and that’s usually good slow. But I admit I’m a little surprised that it’s been radio silence. I think there is a CSS Working Group meeting in Spain this very week though so we’ll see if that ignites anything.

My own feedback said this is partially a conversation about tabbing order, and it definitely is. So then the bigger question becomes, does this tabbing issue need to be solved as a part of masonry? Or can we solve it more broadly? Rachel introduces the idea that it can be more broadly solved.

… my personal hope is that we can land the proposal for reading-order-items before we have interoperable masonry, in whatever form it takes. 

Are there any more fleshed out alternative proposals?

I thought Jen presented strongly that CSS grid is a great place to put masonry layout, but also that it wasn’t arguing against anything else. Rachel Andrew has that “anything else”, which is display: masonry; with more explanation. What’s nice is that it’s not limiting:

 All of the demos in the WebKit post would still be possible.

I assume we’d lose subgrid… (e.g. sharing columns on an element that spans multiple columns) but if it’s the case and otherwise we can do every other thing Jen laid out… then as much as it’s fun to watch two of the biggest companies in the world blogfight, I kinda don’t care which way it goes.

Our hope is that web designers and developers chime in (post to social media, write blog posts) with your thoughts about which direction CSS should take.

Don’t mind if I do.

Do we need Masonry Layout at all?

Jen writes:

Others are questioning whether or not this kind of layout is needed on the web at all — they aren’t sure that well-known websites will use it.

I think people will use it. It can be a compelling way to lay out blocks of content. For “image galleries” alone I feel like it’s worth having a good solution for. To name the most notorious example, this type of layout has been an iconic part of the Pinterest branding since forever. How’s that for a well-known website? I’d love to see the day the actual pinterest.com uses a native web platform masonry.

There are lots of things on the web that have naturally different aspect ratios, like images and Card components with arbitrary content. A “normal” grid layout with perfectly horizontal grid row lines isn’t always a good fit. Here’s an example of a reviews website where the reviews are of different sizes, and a masonry look works well:

Web designers have been trying to pull this layout off in various ways for ages. There are various JavaScript based solutions (using JavaScript for layout isn’t ideal, but when there is no other choice, it happens). Perhaps most famously Masonry, where the 16k+ stars on GitHub is compelling alone.

The cows have made a path here. It’s a cowroad.

Do we need a new way of doing Masonry?

I’ve made the point in the past there are existing ways to pull of this layout entirely in CSS. You can use CSS columns.

You can also use flexbox.

That is literally the layout that masonry is achieving without inventing anything new. But that leads to the next two sections.

This is partially a conversation about tabbing order.

Notice in the example above, the boxes are layed out as going “down” the first column, then back up to the second column at whatever box naturally comes next. This depends on the available width. But it might end up something like this:

[ 1 ] [ 4 ] [ 8 ]
[ 2 ] [ 5 ] [ 9 ]
[ 3 ] [ 6 ]
      [ 7 ]

This is where I’m not 100% sure if problems set in or not. As I currently understand it:

• ✅ Sighted mouse/trackpad user: not a problem
• ✅ 100% screen reader user: not a problem
• ⚠️ User that relies on tabbing through content visually: Maybe a problem??

So I’d love to fully understand if this vertical-by-row stacking order is actually a problem or not. And if it is, and it’s the only problem, are there other ways of solving it other than totally abandoning the columns approach? Is there some version of the (fake) idea .masonry-layout-with-columns { tabbing-order: visual; }?

So then as I understand it, if CSS grid-powered masonry became a thing, it kinda “solves” this by maintaining “as horizontal as-it-can” tabbing order. So tabbing through content goes more like this:

Is that actually better? It seems kinda funky either way to me. I just wouldn’t automatically take it for granted that this horizontal-ish tabbing order is automatically better. If the elements are of wildly different sizes, I can imagine the tabbing being more awkward than the column style tabbing (which is at least predictable).

Although if the columns went down much further than one viewport height, then I do see how the horizontal-ish method is preferable.

The name is a little funny.

The term masonry implies “like a mason would lay out bricks for a brick wall”. That’s funny to me as in that case, there actually are hard “row” lines.

That kind of layout is already totally doable with flexbox and flex wrapping.

So I suppose the actual name masonry doesn’t feel quite right to me, especially for a term getting codified into the language.

I see “waterfall” is a possible alternative name and I think I’d vote that direction (I see there is active discussion). Or maybe the grid-template-rows: off; that actually feels nicely logical.

Didn’t we already go down this road?

Jen reminds:

A mechanism in CSS for “masonry layout” was first proposed by Mozilla in January 2020 as an extension of CSS Grid, and implemented as an experiment behind a flag in Firefox Nightly.

I’ve had a site using that as a “progressive enhancement” for most of the 4 years that’s been out. You can just set up a grid without masonry, and just add it on if it would work nicely.

.grid {
   display: grid;
   grid-template-columns: repeat(2, 1fr);
   gap: 4rem;
   grid-template-rows: masonry;
}

Seems perfectly fine to me. That would work by setting an alternative grid-template-rows on the line above as a fallback if needed or with using @supports to test the property: value pair.

Just because a test version got implemented doesn’t mean the final version has to follow that, I’m just saying I’ve played with it and used it and it seems fine.

Is it right for CSS grid?

Jen writes:

Some people remain skeptical that this capability should be part of CSS Grid

Questioning the current proposal is good. But you can’t just say you don’t like it without a pretty strong why or better alternatives. I didn’t scour the discourse myself, but the only one I see clearly in the article is:

main {
  display: masonry;
  masonry-columns: repeat(5, minmax(28ch, 1fr)); 
}

I don’t hate it, but it is a bit more limited than the fancier possibilities of grid-template-columns.

My main disagreement is that I feel like display is already so overloaded. It’s annoying to me that the same property that dictates the kind of layout the element does internally is the same thing that hides the element entirely. To me since the idea works well within the context of grid already, just use grid. Like it just seems like a natural fit.

Just this kind of control to me is obviously compelling:

And see the post for Jen’s example of using max-content columns which is honestly even more practical.

Mega menus have been hard to code, especially across multiple screen sizes. With CSS Grid Level 3, it becomes incredibly easy. A few lines of code creates a dynamic layout which adds and removes columns one at a time as space allows — without any media/container queries, and with wrapping prevention.

Then you add spanning columns to the party and subgrid and it’s clear me Jen has made a very strong case for adding “masonry” to CSS grid.

More

• Do we ever get multiple values for gap where we can control the space between different rows/columns differently? Does the display: masonry approach allow that where grid would not?
• Can we get a “automatically make tabbing order visually logical, I’m sick of thinking about it and want to re-order and re-arrange things as pleases me” situation going?
• Are there any more fleshed out alternative proposals?
  • UPDATE: Google’s response
• Are there any problems with using CSS grid for this? The advantages seem clear but the disadvantages do not.
• Controlling individual column widths is sweet, should that make its way to CSS columns?