Weighing in on CSS Masonry

I love to see the discussion moving on CSS “masonry” (or “waterfall” or whatever the name may eventually be). The key question at this point seems to be whether this specification should continue to live as a part of grid, or if it should be its own thing.

Kicking off the discussion are this Webkit blog post and this Chrome blog post. I want to give my take.

Should masonry be its own display method outside grid? Absolutely.

I can think of a number of reasons why it should be separate — many of which Rachel Andrew lists in the Chrome blog post above — but one key argument jumped out at me. She only touched on it briefly, but for me it sealed the argument: grid-template-areas.

How developers learn and use grid ¶

Grid is an immensely versatile layout system. You can rely on grid to implicitly place the grid items; you can use grid line numbers to position items in the grid; you can name grid lines and place items using those names. And you can use grid-template-areas to draw an ASCII-art style layout with named areas, then place items into these areas by name.

This last approach allows for an approachable, high-level introduction to grid:

.my-page {
  display: grid;
  grid-template-areas:
    'logo   header header'
    'nav    nav    nav'
    'main   main   sidebar1'
    'main   main   sidebar2';
  grid-template-columns: 1fr 2fr 1fr;
}

Personally, I don’t use grid-template-areas very often. I’m happy with a slightly lower-level approach using numbered or named lines, but I completely understand the appeal of named template areas. From what I’ve seen in discussions and blog posts online, naming template areas has a huge broad appeal, especially among newer CSS developers. It’s approachable and serves as a gentle introduction to the monstrously large set of features available in grid.

For many developers, it appears to me this is the primary — and possibly only — way they know how to use grid.

The problem is, this feature is almost meaningless in masonry.

To educate people about masonry layout, we can’t simply say, “just define a grid and set grid rows to masonry. If that developer’s understanding of grid is limited to named template areas, they will happily type display: grid and, as is their habit, grid-template-areas: and will run into a problem, right out of the gate. What should this property be set to? The way forward for them will not be immediately clear.

This developer has in mind the goal of learning how masonry works, but the way to achieving that goal lies in a deeper understanding of grid, apart from masonry.

A clearer educational path ¶

If masonry is a part of grid, the way to teach masonry becomes: “go learn grid at a deeper level.” Then, upon learning more about grid, the next step becomes: “half of what you just learned about grid does not apply to masonry.”

That sounds like a pretty terrible learning experience.

Masonry has a number of things in common with grid, and a lot of the knowledge of one can be brought to the other, but they also diverge in a lot of ways.

I think it’s far more approachable to teach display: masonry and all the new properties that go with it. Then, at the end of that lesson, you can say, “and the good news is, most of what you just learned applies to grid as well!”

Now, instead of putting in work and being confronted with the news that you didn’t need it all, you get the opposite: after putting in the work, you learn it does double-duty! As a student, I’d prefer that learning experience any day. As a teacher, I’d definitely prefer to give that learning experience.