[css-grid-3][masonry] Masonry Syntax Designer/Developer Feedback

[jensimmons]

Grid-Integrated syntax vs Grid-Independent syntax: Which one and why? What use cases are you excited about, and how do they map to the different syntaxes? Do you have examples? Have you written an article about it?

Read these articles for context:

• Chrome team: Feedback needed: How should we define CSS masonry?
• Safari’s WebKit team: Help us choose the syntax for Masonry in CSS
• Rachel Andrew: Masonry and good defaults
• Miriam Suzanne: Choosing a Masonry Syntax in CSS

[jacobp100]

I’d say masonry and grid are as at least different as grid and flex, so they should be separate display values with their own separate layout properties

Grid and flex share a lot of properties - almost all of the align and justification properties work on both, but justify-items is ignored for flex. I’d guess (correct me if I’m wrong) some options will be ignored for masonry. It’s a lot easier to document what properties are ignored if it depends solely on the layout mode without additional context, as is the case today. It’ll make for a fantastic table too!

I believe the WebKit proposal makes it easier to describe an invalid layout too, if you put masonry layout for both columns and rows. This isn’t an absolute deal breaker - grid already did this with the named areas. But Chrome’s proposal doesn’t suffer from this - everything you write will create a computable layout (like flex)

On the point too WebKit makes about code reuse through sharing properties - this isn’t the only way to do this. You could introduce template-columns as a shorthand for both grid and masonry. It’s a separate conversation - but I think it’s important that point doesn’t become considered the only way to skin this cat

Consider this a vote for Chrome’s proposal. Sorry WebKit 😅❤️

Edit- I spent a bit longer with Safari's demo implementation. I think it's neat that you enabled spanning over multiple tracks - I would have assumed it would be too difficult. I know it's a preview, so there are bugs, but what should margin: auto on these items do in this case? Also, how would you stretch items above to fill in the any blank gaps (as shown below)?

[t0byman]

I prefer the Grid-integrated syntax, because of WebKit's biggest argument: it should easy to learn and the design principle says to build on what's already available in CSS.

Learning a whole other set of properties just for collapsing some rows in a grid (because that's what masonry is imho) sounds very cumbersome, rather unnecessary and even inaccessible to me.

[joakimnl]

Thank you for that great article, @jensimmons. It really made it click for me, how the options differ and what the DX will feel like.

I'm in favour of the Grid-integrated syntax, as it feels like a natural extension of CSS Grid's capabilities. As you mentioned in your article, that's probably because I've used CSS grid a lot. The ability to just tweak a couple of CSS Grid properties in a media query – instead of changing the entire layout mode – really hits home for me.

Looking at all those new properties in the Grid-independent syntax makes my brain hurt.

Just use grid! 😅

[Melluish]

I definitely feel it should be a part of grid rather than its own display type. It feels like too specific of a concept and a subset or type of grid, therefore, it should be integrated into grid.

[Melluish]

Also, I don't have an issue with the masonry keyword tbh. Naming things is hard and we all know what it means.

[angelux]

While I was already convinced that extending the Grid syntax is the right way forward, something immediately stood out to me in the latest WebKit post, emphasis mine:

But a real CSS file is never just five lines of code. Real life is far more complicated. You might want to code a classic Grid layout up to a breakpoint, then switch to a masonry-style layout on wider (or narrower) screens. In that case, switching layouts would require more lines of code with the New Masonry Layout option compared to the Just Use Grid option.

I’ve personally experienced this many times, needing different layouts for various screen sizes. I can vividly imagine how cumbersome it would be to use different syntaxes for the same HTML at different breakpoints. This realistic scenario further solidifies my belief that extending our existing tools (Grid, in this case) is the right approach.

Imagine how much more powerful the minimally extended Grid syntax would be when combined with CSS Variables. You could not only adjust the layout but completely change it by updating just the CSS variables at a given breakpoint.

[bloycey]

Initially my intuitions lead me towards wanting a separate masonry display type.

After reading the article, however, I'm strongly convinced of the integrated "Just use grid" approach. The distinction visually between a grid and a masonry layout is not sufficient for an entirely new display property. Masonry really is just a flavour of grid, or even a collapsed grid.

I like the collapse property too.

I see the distinction somewhat similar to the difference between flex-direction: row and flex-direction: column. Although arguably they could be distinct display properties I'm glad that they are both nested underneath the flex umbrella. Same goes for grid-template-rows: masonry/collapse being a part of grid.

Just use grid!

[ChaosCrafter]

FWIW, I like pack over collapse, but thats just a personal preference.

I'm curious if there would be any way to make other items honour the same arrangements in parallel. I'm thinking being able to specify another set of columns with layout=copy-from-#xxxx where it attempts to honour the original layout in a duplicate space. The case I'm thinking of is a masonary/packed list of images (maybe 3 columns), and paralleling them three columns of image names with each name aligned to the image it's associated with. That can be done by an offset for each name and just having them in the columns with the images, but that will fail if a name is too long to fit in a column, and so the next name needs to be adjusted down a row... (as per the first row in my example) I'm thinking of the way museums and galleries sometimes display image catalogs.

Here's a very rough (and ugly) example of the sort of thing I mean. Ignore the red "Text" in the middle, that was an oops that was going to require I redo everything

[mariusGundersen]

There is so much overlap between grid and masonry that it feels really strange to duplicate all that syntax. I also don't think masonry is going to be used all that much in the real world (once Pinterest design becomes easy it will also become untrendy) so having an entire set of keywords dedicated to it feels like a pollution of keywords.

I'm not sure the defaults for masonry syntax advocated by the Chrome team is very useful either, given that it will often need to be overriden or be redeclared just to be explicit.

The only downside I see for integrated grid syntax is that new features of grid need to take masonry into consideration. I don't know what is in the pipeline for grid so I don't know how much of an issue that actually is.

Given all of this I vote for the grid integrated syntax

[copyandpaetow]

Conceptually, this specific layout is still some kind of a grid, so it makes sense to keep it as a sub-functionality of display: grid. It also aligns better with the story of subgrid as another keyword to use for grid-template-row/column.

I am worried about the adoption of a new display type when there are still people not interested in learning grid. It would be another syntax to learn, which is only somewhat close to the grid syntax.

I vote for the grid-integrated syntax

[Loirooriol]

I am worried about the adoption of a new display type when there are still people not interested in learning grid

I don't really follow your argument. If some people aren't interested in learning grid, how will making grid even more complicated help? If we use a different syntax for masonry, maybe these people will learn this other simpler syntax.

[copyandpaetow]

I am worried about the adoption of a new display type when there are still people not interested in learning grid

I don't really follow your argument. If some people aren't interested in learning grid, how will making grid even more complicated help? If we use a different syntax for masonry, maybe these people will learn this other simpler syntax.

Thanks, I see how it was not clear enough. I would assume that people not having learned grid by now, would also not learn the new masonry syntax. These will likely not use it regardless. But there are people who postponed it for longer. For these / beginners / most people having to learn just a few more keywords is far easier / the burden of entry far lower than to learn a whole new display type. To me, grid is not getting more complex in general. If you don't plan on showing a masonry grid, nothing really changes.

[fschroiff]

Masonry feels like an exotic use-case. If it has to be incorporated in the CSS spec I'd argue for making it a separate rule. CSS Grid is complex enough as is.

[dutchcelt]

An independent masonry (grid) feature would (in my mind) allow it to grow in less gridlike ways. It would be about masonry and not about grids. The nature of masonry, with its dynamic placement, makes it a candidate for more variations of placing content dynamically. Do masonry tracks need to be straight lines? Could we have spirals? Assign 'boxes' with priority/preference that directly or indirectly influence the dynamic placement of content. I fear if it's an extension of the current grid, the door to a new, alternative layout will be more challenging to open. I apologise if any of this has been mentioned before.

[GrimLink]

Masonry should be its own layout type.

Same as with other layouts there is always some overlap. We could make the same arguments for flexbox yet we have not combined it, and that's a good thing.

Also from a learning perspective, it is easier to learn some one new masonry specific properties and values, instead trying to make them learn both grid and masonry and what properties and values don't work together

[JoshTumath]

I think with whatever we decide, the masonry layout should be enabled using the display property. It makes it much clearer that we're opting into a different kind of layout than grid.

Also, the WebKit team have proposed expanding some of the grid-* properties for both grid and masonry and potentially others like even the default 'flow' layout type. I am very interested to see what people think about that. Is that enough to merit making some of the grid-* properties more general-purpose?

[TheUnlocked]

If I was a developer who didn't understand display: grid, I don't think I would be likely to take the time to thoroughly learn display: masonry when I needed to use it either. I would probably just search for "CSS masonry layout" (or similar), find the page on MDN, and copy/tweak the CSS there until I got something that did what I wanted.

However, if I was a developer who did understand grid layouts, being able to apply my existing knowledge to masonry would feel like much less of a burden than needing to learn a whole new set of concepts for masonry (or even just needing to memorize how grid properties map to masonry properties).

The breakpoints use case mentioned by the Webkit team and others here is also particularly compelling. Even the grid novice would probably prefer to only need to tweak one or two properties they half-understand rather than try to wrangle a whole new set of CSS properties.

[astearns]

The WebKit article asserts that the “just use grid” option would make it easier to switch between grid and masonry at a breakpoint. I’d like to see one or more examples that demonstrate this, as it’s not entirely clear to me that the two layouts would share enough declarations to make this easier or clearer than a separate display type.

[HeyHemi-dev]

I'm strongly in favor of introducing a separate display type, such as display: masonry.*

I've explored content from the WebKit and Chrome teams, along with other blogs and videos, and have worked on multiple layouts that ideally would use a masonry approach (e.g., a wall of reviews or a Pinterest clone). From my perspective, adding masonry to the existing grid model introduces unnecessary complexity—both technically and conceptually. Here are two examples that underscore why masonry and grid are inherently different:

Problem 1: Confusion with Masonry on Both Axes

.masonry {
  display: grid;
  grid-template-columns: masonry;
  grid-template-rows: masonry;
}

What would happen in this case? Is it just up to developers to remember to avoid this configuration? This ambiguity indicates a fundamental mismatch between masonry and grid.

Problem 2: Over Complication When Changing the Masonry Axis (esp. with template areas)

Not to mention, 'areas' isn't an ideal concept for defining rows or columns in a masonry layout.

.masonry {
  display: grid;
  grid-template-areas: "a b c";
  grid-template-rows: masonry;
}

/* Switch masonry direction. */
.masonry {
  grid-template-areas: "a" "b" "c"; /* Each row is quoted. */
  grid-template-rows: unset;
  grid-template-columns: masonry;
}

Re-declaring template areas like this makes it clear that we are stretching the grid model beyond its intended use to fit masonry behavior.

---

These are just two examples, but there are undoubtedly many more—both existing and yet to come—that illustrate the challenges of merging grid and masonry. Moreover, I'm not seeing any compelling advantages in tying the two together, especially when the conceptual separation could be much cleaner and easier to use.

IMHO introducing a dedicated display type would provide a clearer, more intuitive approach to handling these kinds of layouts, avoiding the complexity and ambiguity that arise from trying to force masonry behavior into the existing grid framework.

Footnotes * I'm not convinced using a metaphor (masonry) is the right approach for the final display type name.

[arif891]

I want to ensure that my layout doesn’t break if display: masonry isn’t supported. I think using CSS Grid as a fallback would be a good solution.

[bravecrayon]

I prefer the idea of leveraging the existing grid syntax and properties. Masonry seems to be an extension of grid. Grid is a good, generic concept for creating many specific layouts, of which masonry is but one endpoint. Masonry is a tweak or modification; a style of grid.

Elevating a specific way of displaying boxes on a grid to a whole new display value, while adding new properties/syntax to support that, seems cumbersome. You'd really need a good case for why to do that. There exists already, in my opinion, too many different ways with difficult-to-remember syntax and keywords to flow content.

I can very easily imagine myself starting with "grid" layout at the onset of a project and needing to switch to masonry style later. I would need to rewrite a bunch of CSS if it was its own display value with specific supporting properties.

On the second point of what to call it if it was a keyword for grid-template-*, using "collapse" is ok, but I'd prefer something like "pack" or "packed", as in "packed tightly", because I think it's more memorable for my visual brain. I suppose "stacked" could also work, but doesn't work well for the horizontal axis. Also, I have already associated "collapse" with border-collapse, which would mean the same keyword means two different concepts/effects based on context, so naming it something more unique like "packed" is preferable.

[whytspace]

Firstly, I am happy that this is coming to CSS. It will be a great addition to the new layout methods flexbox and grid. 👍

I've read both the blog posts from the WebKit and the Chrome team and I do see valid points in both of them.

Webkits proposal of having all the existing power of grid also available in the new masonry layout sounds great.

However, I think that the grid syntax is already quite powerful / complicated (however you wanna see it) and – from my experiance – puts a huge mental burden on the developers using it.

But making some values invalid in some specific cases is not a good idea. I think instead it should be it's own individual syntax, inspired by grid, same as grid was inspired by flexbox.

I am therefore voting for a separate display: masonry. other names are also fine, "waterfall" for example

[HeyHemi-dev]

I want to ensure that my layout doesn’t break if display: masonry isn’t supported. I think using CSS Grid as a fallback would be a good solution.

I'd argue this is burdening the future for the sake of the present.

The fallback for an unsupported display:masonry should be the same as the fallback for an unsupported display:flex or display:grid. If you say it's different because flex and grid are widely supported; then the same argument will apply for a new display:masonry within a few short months/years.

[alcinnz]

My points have already been stated in this thread, so I'll just vote:

Make Masonry part of Grid!

[jacobp100]

@HeyHemi-dev I think the argument was in favour of a separate display keyword so you could write a grid layout and a masonry layout, and have it fall back automatically. Although we do have supports queries now so not so sure it’s a deal breaker

[whytspace]

I see the distinction somewhat similar to the difference between flex-direction: row and flex-direction: column. Although arguably they could be distinct display properties I'm glad that they are both nested underneath the flex umbrella. Same goes for grid-template-rows: masonry/collapse being a part of grid.

I don't understand that comparison: flex-direction: row and flex-direction: column are the same propery with a differnet value. makes sense. But grid-template-rows: masonry and it's counterpart grid-template-columns: masonry would be two different properties with the same value. does not feel very intuitive for me

[ziofat]

I recommend creating a separate specification for masonry. While the current grid specification can handle masonry layouts for now, the future of masonry is uncertain. Adding masonry rules to the grid specification could increase its complexity significantly.

[bravecrayon]

@ziofat

While the current grid specification can handle masonry layouts for now, the future of masonry is uncertain. Adding masonry rules to the grid specification could increase its complexity significantly.

If the overall concern that is driving opinions toward a new display value is all about masonry's future (maybe it's not?), why couldn't specific masonry-* properties be introduced to handle that when the time comes?

[jacobp100]

@bravecrayon you can't make grid handle everything. Even for a single row (no wrapping), grid cannot do everything flexbox does. Here's an example where the 'center' content stays in the center unless it's impeded by the left and/or right content - it's not possible with grid and you realistically can't adapt grid to do this

[ziofat]

@bravecrayon If we were to introduce properties like masonry-*, it would strengthen the argument for a separate masonry specification. This is because these properties would be distinct from grid functionality. Additionally, this approach would maintain consistency with the existing patterns of flex-* properties for display: flex and grid-* properties for display: grid.