[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
• Ahmad Shadeed: Should masonry be part of CSS grid? — compares real world examples with breakpoints and fallbacks
• 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.

[miragecraft]

Initially I leaned toward “just use grid” simply due to it requiring fewer new CSS properties, which feels more efficient at first glance.

However after thinking about it some more I am coming around to display:masonry.

1. Simplicity should not be defined as lines of code or number of characters, but rather conceptual simplicity and clarity of intent. If all we care about is character count then everyone would be writing minified CSS.

   In that respect “just use grid” is in the former camp, while display:masonry is in the latter, and I believe clarity of intent is what we should be optimizing for.

   How does display:masonry achieve clarity of intent with extra properties?

   First, by reducing the cognitive load due to not having to think about the masonry axis; second, by having a simpler syntax for masonry-template-areas in the row direction compared to grid-template-areas, which makes switching direction a breeze.

2. Requiring developer to switch mental models in the case of display:masonry is actually a good thing, as it simplifies the mental model for both grid and masonry.

   The argument that having a separate display mode is more burdensome than stuffing it into an already complicate grid layout does not make sense to me, as it’s much easier to learn two simpler system than one really complicated system. And grid is complicated enough already.

3. WebKit team’s argument for extensibility of “just use grid” vs display:masonry did not focus on the fact that “just use grid” forces masonry to accept grid limitations for future feature extensions, but rather hinges on a “slippery slope” argument regarding potential display models in the future.

   I feel technical limitation is much more important in the browser environment where we have to live with our decisions forever. There is nothing forcing us to not extend grid when it makes sense (ex. pillars layout) even if display:masonry exists. It may not feel ideologically pure, but CSS to me has never been particularly concerned with that.

   However if we do discover a use case for a potential masonry feature that is impossible to implement when integrated into the grid, that would be a much bigger problem to deal with.

4. WebKit’s team’s argument that the default value of repeat(auto-fill, auto) is not actually desirable hinges on the fact that images could lose sharpness when stretched too much.

   This does not consider the potential of responsive images, and future formats such as JPEG XL where the browser can intelligently request for the appropriate image resolutions.

   In addition, this can be solved simply by applying a max-width on the masonry container itself, or justify-content:start to turn off track stretching.

   In fact, this may not even be a concern for certain use cases such as digital signages and kiosks where the display size is known.

   Finally, you may simply accept the fact that your images could lose sharpness at larger viewport sizes. Perfect is the enemy of the good.

5. I see some commenters putting forth the argument that masonry is “too exotic” to deserve its own display type which I feel is a bit silly, as there is nothing special about display values, aren’t we assigning undue importance to it?

6. As for graceful degradation from masonry to grid, we already have the @supports at-rule, so it’s a non-issue.

[gg-phntms]

Another vote for display: masonry here.

@miragecraft 's points 1 and 2 are the big ones for me (clarity of intent, and separate mental models).

To me it seems that the argument for integrating masonry into grid is to make the code as concise as possible - fine in theory, but perhaps misguided when the ultimate aim is clarity and ease of use.

[creativeer]

After reading the article from Jen Simmons i'm also for the integrated grid syntax. This just make sense. A masonry layout is at the end of the day just a variation of a grid, so with some settings in grid, it should be possible to describe the flow of the masonry.

[mlandisbqs]

Here's another vote for Grid Integrated - the argument from webkit is compelling and I feel no reason to repeat it here, but I'll add that this approach feels more syntactically cohesive from a responsibility perspective.

[ecbypi]

My 2 cents: integrating masonry into display: grid seems like a safer approach that's less disruptive to people browsing the web.

Overall, I'm "meh, why?" on incorporating masonry into the browser as I don't find it a friendly experience for people that have issues with focus or cognitive challenges.

It's a perennial issue getting people to be aware of and care about inclusivity in design and engineering; using display: grid seems like a safer, more conservative approach to start.

From what I can see, the display: grid approach doesn't seem to preclude implementing display: masonry in the future after learning how people use it as part of display: grid (for better or for worse) and seeing what limitations need to be addressed.

Other thoughts:

• For me, the points about "masonry's future" are missing meaningful, genuinely useful, accessible examples that demonstrate why display: masonry is required, how it would simplify the implementation in browsers, or be easier for developers to use than an implementation using display: grid.
• Instead of optimizing for assumptions about developer convenience, I'd rather optimize for customer experience and display: grid would result in fewer broken interfaces. Eventual evergreen support in all browsers is an assumption and ignores people depending on unsupported devices.
• It's convenient when the model to teach a technology is simple, but the absence of that doesn't make the technology unteachable.
• To share my own assumption to counter other assumptions: simplicity for teaching or usage could be offset by confusion from similarities between display: grid and display: masonry. Naming the properties differently does not unequivocally prevent people from making false assumptions about similarities between them.

[bravecrayon]

Additionally, this approach would maintain consistency with the existing patterns of flex-* properties for display: flex and grid-* properties for display: grid.

@ziofat Fair point, consistency is preferable.

[ShaunaGordon]

This table, and the argument based off of it...kind of confuses me:

Grid	Masonry	Pillar	Another future feature
display: grid	display: masonry	display: pillar	display: foobar
grid-template-columns	masonry-template-tracks	pillar-template-columns	foobar-template-baz
grid-column	masonry-track	pillar-column	foobar-qux
grid-template-areas	masonry-template-areas	pillar-template-areas	foobar-template-areas
… etc …	… etc …	… etc …	… etc …

...why do we keep adding a display type prefix to what is essentially the same property.

The author keeps talking about cognitive overhead and confusing syntax, but then gives the example of using grid properties in a flow layout:

article {
  display: block; /* default value, unnecessary to state */
  grid-template-columns: 1fr 1fr minmax(15ch, 30ch) minmax(15ch, 30ch) 1fr;
  grid-default-column: 3 / 5;
}

How is this not equally confusing as the New Masonry Display option?

Why don't we just...drop the prefix? grid-template-columns simply becomes template-columns, then it doesn't matter whether it's display: grid, display: block, or display: masonry, and we don't keep adding prefixed versions of what are essentially the same properties. Any property that doesn't work in a given context is, like all other unsupported CSS properties, simply ignored.

Then we have:

article {
  display: block; /* default value, unnecessary to state */
  template-columns: 1fr 1fr minmax(15ch, 30ch) minmax(15ch, 30ch) 1fr;
  default-column: 3 / 5;
}

And if we want to change display: block to masonry or grid, the other properties don't have to change, and the layout simply reflows per the context's other defaults.

[querkmachine]

Thoughts, with the caveat that I'm not deep in the weeds of how specifications or CSS works behind the scenes, I'm just a developer who uses it every day. (Though I guess that's exactly who you want to feed back on this!)

I prefer the grid-integrated syntax for a number of reasons:

1. In my mind, there are only a few different layout modes in CSS. There's 'the flow' (the default), a few tools for fiddling or breaking out of the flow (float, position), one-dimensional layout (flex) and two-dimensional layout (grid). Masonry, in my mind, is another form of two-dimensional layout with a significant amount of overlap with grid, so making masonry an extension of grid makes intuitive sense to me.
2. Reducing the number of new properties being added to CSS seems sensible, especially as many of the properties proposed in the standalone masonry syntax do virtually the same thing as their grid counterparts.
3. Keeping things familiar reduces the amount of new stuff that has to be learned and taught. As an on-again-off-again tutor of frontend things, I've noticed that a lot of people find flex and grid layouts intimidating to learn and use. Being able to change a grid to a masonry with just one or two lines of CSS makes learning masonry and grid a two-in-one package. In my mind, grid already having a 'complex' syntax is more reason to merge masonry into it.
4. Whilst I appreciate (and kind of agree) with the argument that a separate syntax permits setting sensible defaults out-of-the-box, I don't see this as a showstopping difference. As a developer I'm very used to overwriting CSS's 'sensible defaults', this would just be another instance of that. I'm not sure about other browsers, but Firefox's devtools are also very good at pointing out where incompatible properties are being used together and why, which makes the idea of having to debug 'illegal' layouts not feel particularly daunting.
5. The Chrome team's argument that masonry layout needs to be separate for performance reasons also doesn't hold much water for me. We shouldn't be making spec decisions on the basis of present-day engine limitations. The developer experience should be the priority when it comes to syntax decisions.[^1]
6. As noted by commenters above, having them integrated makes progressively enhancing a grid into a masonry layout (or dynamically switching between them) a lot simpler.
7. Having masonry integrated with grid doesn't preclude having masonry-* properties that modify masonry-specific features in future. Having masonry start as a completely separate syntax does preclude it leveraging the existing features of grid in future, without also requiring vendors to provide the indefinite backwards compatibility for its unique properties.

[^1]: Is there literally not some W3C mantra somewhere about favouring users over developers, favouring developers over browser vendors, etc.? Edit: The priority of constituencies! Thanks @JoshTumath for the reminder.

[windsywinds]

I also initially favoured Chrome's proposal but after reading WebKit's justification for "Just Use Grid", I agree with their reasoning for display: grid as per design principles.

1. Reuse existing patterns and properties
2. It should be simple to learn and simple to use

Both of these support Just Use Grid instead of having to learn an entire new syntax and layout system.
Further, I see points raised as to how difficult display: grid would be if masonry use cases changed or expanded, but this doesn't make sense as we can simply override properties and implement new ones without creating an entire new syntax and properties, the same way we do already with existing layouts and properties. New masonry specific related properties can be added to display: grid, or existing properties adapted in line with reusability, if such use cases arise and are required without disrupting how it currently operates at a basic level inline with current use and understanding. In an extreme case, display: masonry can still be implemented in future if masonry ever grew to be so unique and adaptable to require its own layout system.

[alcinnz]

I wrote my quick thoughts as a blogpost: https://argonaut-constellation.org/2024/10/27/masonry-syntax.html

Probably could've made it a comment, but I like putting in the context of my blog!

Again, my vote is: Just use grid!

[shadeed]

I wrote about my thoughts here: https://ishadeed.com/article/css-grid-masonry/. In short, I vote for integrating masonry as part of CSS grid.

[astearns]

@shadeed thanks for all the examples in your post!

I’m working through the practical example in 4.2, which (I think) uses grid at larger widths, masonry at smaller widths, but reverts to grid if it contains a .card-fixed element. You have example code for one option, and I have tried to work up what it would look like in the other (please let me know if I have incorrect assumptions about the example or my code can be improved)

Your display:masonry version (with my additional comment)

.masonry {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
  padding: 1rem;

  @media (min-width: 700px) {
    display: masonry;
    masonry-template-tracks: repeat(3, 1fr);
    gap: 10px;
    padding: 0;

    &:has(.card-fixed) {
      display: grid;
      /* also reset gap and padding? */
      /* but any grid- or masonry-specific differences are OK */
    }
  }
}

My “just use grid” version

.just-use-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
  padding: 1rem;

  @media (min-width: 700px) {
    grid-template-columns: repeat(3, 1fr);
    grid-template-rows: masonry;
    gap: 10px;
    padding: 0;

    &:has(.card-fixed) {
      grid-template-columns: 1fr;
      grid-template-rows: none;
      /* also reset gap and padding? */
      /* and reset anything else in grid that differs */
    }
  }
}

To my eye the nested grid-masonry-grid decisions look more clear and simple with a display change.

[blynx]

I'd like to see it integrated into CSS Grids.

My conclusion is, that, practically all Layouts in some form are originating from a grid system. That alone wouldn't be a good reason for a technical decision. Yet, having read Ahmad Shadeeds thorough examination and having had a brief look at the Webkit Teams article, I think there is/might be just this "underlying principle" at work, which would allow this solution to be so elegant.

Especially the grid-default-column article-layout example triggered that motion in me. Initially I was reluctant to accept Ahmads statement "Masonry is a grid, right?", because the masonry result itself is not a grid. It lacks one of the tracks: vertically or horizontally. But then, it is based on a grid system having one dimension "collapsed".

So, it is nonetheless constructed on a grid system. Even one/two column layouts, simple type areas in books—the laying of the text body, page numbers, etc.—are fundamentally based on a grid system, which has been constructed beforehand in the design process. Ask designers! (Disclaimer: I studied graphic design before ending up as some IT guy) And I want want to joyfully refer to Josef Müller-Brockmanns Grid Systems Book here. (p. 50ff.)

One might be afraid to overload display: grid;, especially looking the grid-default-column example. But I think it's a misleading fear. grid-default-column just expresses the very design thought which underlies this design, for example. Ahmad outlines very well the practical sides of integrating masonry into CSS Grids, the non-duplication of code for fallbacks, for example. I believe that this elegant simplicity originates from that underlying principle, that, in the end, all layouts are based on grid systems. Shall we add a display mode for every form of layout then? I think this would be the actual overload.

Masonry is a very particular instance of a layout, grids/grid systems are the principle.

PS: I also prefer to remove the term "masonry" and go with something according to "collapsed".

PPS:

Would Flexbox become obsolete at some point? Maybe, and I think I wouldn't mind. Already now, it is possible to replace many or most Flexbox Layouts with CSS Grids. Flexbox might just be more convenient - be it for the syntax or the habit. One Flexbox layout I believe is not possible with CSS Grids could be wrapping lines with stretching items. I have a feeling that masonry grids could be able to accomplish that in some way.

[Th3S4mur41]

I initially preferred having masonry separated from grid. The main reason was that a lot of developers still struggle with grid and the idea of having masonry split from it would allow those developers to have an easier path learning masonry without necessarily having to deal with grid first.

However, after reading @jensimmons' post, I must acknowledge that display: masonry would also mean introducing a bunch of new masonry dedicated properties instead of reusing existing one from grid. IMO, having separate properties would heavily increase the cognitive load for both new and experienced developers.

The only way, display: masonry would remain a good option is if we were able to reuse all the properties, we need from grid without introducing separate ones, same as e.g. grid-gap and flex-gap were rid of the prefix to become just gap.

[dagadbm]

I support "Just use Grid". At first It seemed like it made sense to make it all separate but after seeing some of the example thrown around I think keeping it as part of a grid is the right call. First of all, semantically masonry is just a grid with particular properties, it makes no sense to create yet another set of properties.

Things are as confusing as they are right now with flex and grid sometimes not knowing which properties I should use to adjust layouts.

You have also decided on the gap keyword to be more generic and focus on what it does, a gap between things, no matter if they are grid like or flex like. Why should you create a new display (which is something that should not be done lightly) when it masonry literally looks like a grid.

To me the display property should be used very sparingly and for very explicit things. I feel like adding a new display is using a bazooka to kill a fly to create such a high level of complexity just because someone wants to name a particular type of grid layout totally different.

This also means that the name of this "UX pattern" is bleeding into the implementation of the browser, what if people grow tired of this name and rebrand it some years in the future? I think we all are tired of having to deal with inconsistent naming in our own codebases, would be terrible to have to do the same here. I also believe it should not have the name masonry anywhere.

[shanekunz]

I’m going to be blunt because this feels over-intellectualized: not everyone needs to learn CSS or programming, but we definitely don’t need more syntax clutter. Developers still struggle with flexbox, and grid isn’t as widely adopted as it should be. Meanwhile, Chrome keeps rolling out new features that most people probably barely use or have time to learn.

Honestly, I’d rather see a pause on new features so tutorials can catch up. Just make this a grid property—developers can’t keep up with endless new syntax. If it works 90% of the time, throw a console warning for edge cases and call it a day.

Just my two cents to speak for web devs who aren't active in GitHub discussions.

That said, it’s a great idea overall.

[chrisbowes]

I'm going with webkit proposal. Masonry is a grid variant, but a grid nonetheless.

I see above a comnent saying that Masonry and a fixed grid are as distinct as Grid and Flexbox, but I disagree on that. Flex is used for layout and alignment, even in a single block element, so the distinction between that and a grid is pretty clear cut.

The lack of a fallback in the chrome proposal for adding a entire new display property is too limiting, wheras falling back to a regular grid is sufficient to not break any layouts.

[johncmunson]

Strong pros and cons for both sides. Maybe this just means we're not ready yet for first-class masonry support in CSS.

[jgerken]

I vote for the webkit proposal. For me, like most others here, masonry is a grid. Additionally, I don't like the mansonry layout and would love to have an option in the browser to turn it off - this is likelier to happen if the layout is grid-based.

[johncmunson]

Conceptually, I kinda take issue with the statement that a masonry layout is a type of grid layout.

In my opinion, a grid layout is defined by the presence of both columns and rows, creating a uniform, grid-like structure with consistent alignment in both directions. In contrast, a masonry layout is primarily column-based, with items organized into columns but not constrained by row alignment.

For this reason, my vote is for display: masonry.