[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

[gavinmorrow]

I support the webkit proposal (just use grid), for all the reasons stated above especially progressive enhancement.

I also really like the mental model of masonry just being a collapsed grid axis.

[owennicol]

I support the Grid syntax. Like others have said above, it’s easier to learn less duplicative and it’s easier to make responsive/fallback in unsupported browsers.

[JoshTumath]

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

What would need to happen to make us 'ready'?

[amjedidiah]

I'll keep it simple. Grid-integrated syntax

[alkorlos]

Use of masonry, regardless of syntax or naming, goes beyond a "Pinterest design." Its capabilities will remain relevant and in demand over the long term, for example:

Desktop:

Mobile:

A simple example with three blocks: text, button and image.

On desktop the button is positioned above the bottom edge of the image, so using grid won’t work here. Two columns are needed: one for the text and button, and the other for the image.

On mobile the image is placed between the text and button, and there’s no simple way to move a block from one column to another.

One approach is to use display: contents; on the columns and reorder the elements, but this solution may not be easy to understand and maintain. Another option is to add two identical images in the HTML and show/hide them depending on screen size, either isn’t an ideal solution.

masonry makes this very easy.

New Masonry Layout:

.masonry {
  display: masonry;
  masonry-template-tracks: 50% 1fr;
  @media (width <= 992px) {
    display: block;
  }
}

Just Use Grid:

.just-use-grid {
  display: grid;
  grid-template-rows: masonry;
  grid-template-columns: 50% 1fr;
  @media (width <= 992px) {
    display: block;
  }
}

[alkorlos]

For me display: masonry; is clearer and more convenient.

I read articles from the WebKit and Chrome teams, as well as several blog posts. Main arguments for Just Use Grid:

The Just Use Grid option leans into the idea that CSS Grid is a major layout mechanism for web pages, and we should keep expanding it to be more and more powerful.

Source Help us choose the final syntax for Masonry in CSS; Extensibility

The idea of using a single mechanism to create any layout is appealing.

At the same time if the Just Use Grid approach is implemented there would be many properties and values valid only for grid or only for masonry. Think avoid this kind of behavior would be good.

Let’s be honest, a layout is a major part of a web page that makes it hard to apply progressive enhancement.

Source Should masonry be part of CSS grid?; If the new syntax is supported now, how we should use it?

Article then provides examples showing that implementing progressive enhancement for the New Masonry Layout requires more styles and the use of @supports.

Over time support for masonry will appear in all browsers, the priority now is to create an optimal solution to avoid difficulties future work. Besides, most developers use build tools, so such progressive enhancement doesn't need to be written manually. It's enough to use display: masonry; and, when necessary, the PostCSS plugin will automatically generate the required styles, based on the browserslist.

If we go with the new syntax, then changing a layout will require changing the whole layout module (grid, masonry, or flex). This is too much work.

Source Should masonry be part of CSS grid?; Responsive design

The potential convenience of changing a layout at breakpoints seems like a strong argument for Just Use Grid. However I haven't seen examples showing in practice that Just Use Grid is better in this case.

On this matter I agree with @astearns, in this comment, a comparison of two style examples is shown, and for me changing a layout at breakpoints using the New Masonry Layout looks clearer.

At the same time overriding the direction in Just Use Grid is inconvenient, if I understand correctly:

.just-use-grid {
  display: grid;
  grid-template-rows: masonry;
}

.just-use-gridy--modificator {
  grid-template-rows: unset;
  grid-template-columns: masonry;
}

New Masonry Layout:

.masonry {
  display: masonry;
}

.masonry {
  masonry-direction: row;
}

[kentcdodds]

I’ve been following the discussion here, and I think an important guiding principle is to avoid prioritizing short-term issues over long-term maintainability and usability. While baking masonry into the grid spec would indeed help with progressive enhancement, that challenge is temporary. As browser support catches up, the progressive enhancement issue fades, but the learning complexity and configuration burden would remain.

Adding display: masonry might duplicate some grid features and be harder (not impossible) to progressively enhance, but it would provide a simpler, more intuitive approach for developers, especially those who may only need masonry layouts occasionally. Over time, I think we benefit more from a distinct display: masonry property that’s straightforward to learn and configure than from a tightly integrated but complex grid enhancement.

[qxuken]

I support the Chrome team's proposal, as masonry is distinct enough from grid layouts to justify its own display: masonry option.

Keeping masonry separate will help avoid further complicating the grid syntax.

Having separate mental model is also important and I think separate display option will give that.

While the lack of a fallback to grid is a limitation, it may not be very effective anyway. Projects that require wider browser support are likely to use a more universal JavaScript approach.

[PrudveeT]

After going through some articles display: masonry looks overkill.

[Benimation]

I'm leaning towards display: masonry, because it looks cleaner and simpler to me.

Furthermore, grid already has overlap with flex, so features overlapping with each other is not unheard of. So I think what it comes down to: do we want to pack features together to create a single powerful feature, or multiple simple features tailored to their own use-case.

Also, progressive enhancement is still possible by providing multiple display properties, where masonry will be ignored by browsers that lack support.

[Lancear]

Leaning towards the grid integrated approach, mainly due to the reuse of properties, as described in Webkit's blog, making it easier to learn and remember in my opinion.

For example — when Flexbox was invented, it came with the Alignment properties (justify-content, align-items, etc). Then when Grid came along, those same properties were reused for a similar but slightly different purpose. New properties were added (justify-items) matching the existing pattern (align-items) to extend the feature.

Same with gap. When multicolumn was invented, a new column-gap property provided a way to define the space between columns. A decade later, when the CSSWG needed a way to define space between grid columns, the column-gap property was repurposed. It got a corresponding row-gap property and a new shorthand, gap, to be more universal, and eventually made its way to Flexbox as well. It took a couple tries, but the CSSWG realized it would be a mistake to keep creating separate gap properties for different contexts — column-gap + grid-gap + flex-gap… It’s better to repurpose what already exists.

However, just like we did with gap, it should always be possible to retroactively merge properties in a shorthand alias when masonry had some time to grow in the real world and we have a better understanding on the overlaps and differences. Yet splitting masonry to their own display retroactively is less feasible.

So no strong opinion from my side, but hope the concerns about having separate properties for different contexts can be addressed with shorthand aliases in the future no matter the approach we choose now.

[DmitryMakhnev]

I vote for display: masonry, because it provides distinction and more space for independent design in future.