[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.

But I am very interested to see what people think about using the various grid-* properties for both layout types and potentially other types in the future.

[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.