The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dan-zakirov <alexodiy@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: glendaviesnz <glendaviesnz@git.wordpress.org>
Co-authored-by: melchoyce <melchoyce@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dan-zakirov! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Thanks for the PR.

Are you aware that the implementation of display: grid-lanes is being considered to ideally achieve Masonry layouts using only CSS? Personally, I would like to propose that we consider enhancing the Gallery block after this CSS specification is finalized and implemented in all major browsers.

• https://webkit.org/blog/17660/introducing-css-grid-lanes/
• https://css-tricks.com/masonry-layout-is-now-grid-lanes/

P.S. If you could keep the pull request description as concise as possible, it would reduce the burden on reviewers.

Thanks for the PR.

Are you aware that the implementation of display: grid-lanes is being considered to ideally achieve Masonry layouts using only CSS? Personally, I would like to propose that we consider enhancing the Gallery block after this CSS specification is finalized and implemented in all major browsers.

• https://webkit.org/blog/17660/introducing-css-grid-lanes/
• https://css-tricks.com/masonry-layout-is-now-grid-lanes/

P.S. If you could keep the pull request description as concise as possible, it would reduce the burden on reviewers.

Hi @t-hamano, thanks for the review.

display: grid-lanes is Safari Technology Preview only and the spec isn't finalised yet. Recent precedents: subgrid took 6 years from spec to all-browser support, and Mozilla's earlier grid-template-rows: masonry shipped behind a Firefox flag in 2020 only to be deprecated 5 years later. A realistic wait for grid-lanes across all browsers is 3–5 years, on top of the 5 years #28247 has already been open.

CSS multi-column is the only pure-CSS, cross-browser path to masonry today, and Gutenberg already uses it internally (#49958). Because this is a block style variation, swapping column-count for grid-lanes later is an internal CSS change — no migration needed. #42240 stays the right place to track that upgrade.

If keeping it out of WP Core minors is the concern, happy to gate the registration behind IS_GUTENBERG_PLUGIN.

Got it on the description length - I'll trim this one in a follow-up push and keep future PRs more concise. Thanks for the heads-up

Thanks for the ping 👍

Quickly catching up here, but I'm not sure about the masonry block style variation approach. This feels like plugin territory for me until there is a complete solution.

One reason is this proposal isn't actually a true masonry layout. So the claim this is just a simple swap of column-count to grid-lanes is incorrect. The order of the images will change making it a breaking visual change for some users.

Additionally, the grid-lanes proposal should offer a lot more options and functionality. Things that will likely need settings to be configured rather than styles only, making block style variations potentially inadequate long term.

With advancements to the Grid block and its layout capabilities, I wonder if there might be some way to leverage that in the future to achieve a full featured masonry layout for the Gallery block. It might even allow column spans, waterfall vs brick directions etc.

Thanks @aaronrobertshaw - fair point on column-major flow. Before we close this PR, a couple of things worth raising:

The screenshot below shows the actual UX gap motivating this: Gallery with imageCrop: off produces uneven column heights and visible vertical gaps between rows, and there's no current plan to address that in core. The PR is the simplest CSS-only fix for that, using a feature stable across browsers for 10 years.

There's a broader pattern worth raising too. Each Gallery improvement has had its own context, but the cumulative result is the same - the block has effectively stood still on this kind of layout request:

The last row is the most direct: the project already considers this technique production-grade for its own UI. (A keyboard reading-order concern was raised post-merge there by @KevinBatdorf - fair point in general, but the impact is much smaller for an image gallery, where each figure is a single tab stop, than for a grid of interactive controls.)

Each individual decision above has been reasonable on its own, but together they leave Gallery in a state where the same requests come back year after year and core ships nothing on them. This PR is intentionally narrow to break that loop with the smallest possible step.

I'm proposing two paths:

1. Style variation + concession: rename to is-style-masonry-columns, gate registration behind IS_GUTENBERG_PLUGIN. Keeps it out of Core minors while grid-lanes matures; addresses the "not true masonry" framing.
2. Layout type: re-scope as supports.layout.allowedTypes: ['flex', 'masonry'] so future grid-lanes settings have a UI home - directly answers the "style variation inadequate long-term" concern.

A few questions, if I may:

• Which of the two paths above would be more workable from your side? Simply waiting for grid-lanes to be adopted across all major browsers is realistically several years away, and New Block: Flowing Masonry Gallery #28247 has already been open for five.
• If neither feels right, would you have a concrete near-term direction in mind that could close New Block: Flowing Masonry Gallery #28247 within the next 6–12 months?
• Separately from this PR - is there any plan to address the existing imageCrop: off gaps in Gallery, or is the current behaviour considered acceptable?

To be clear, none of this is meant as criticism - just trying to understand how Gallery and layout requests of this kind fit into the project's broader direction. Happy to take whichever path makes sense, and grateful for the time you've spent reviewing.

Thanks for the continued thoughts and effort here @dan-zakirov 👍

You'll get no arguments from me that the imageCrop: off results aren't ideal. The plan as I'm aware of is that once there is a native CSS masonry layout, it will be ready for Core.

The PR is the simplest CSS-only fix for that, using a feature stable across browsers for 10 years.

As noted, what's proposed isn't a masonry layout, so conflating this proposal with a masonry layout isn't very helpful in moving things forward.

the project already considers this technique production-grade for its own UI

This is definitely a different context than rendering content on a site's frontend where we have backward compatibility commitments to honour. So it's use in the UI can't be used to justify it's use for the Gallery layout.

Which of the two paths above would be more workable from your side?

To me personally, neither path. This is still best left to a plugin or theme until a clean solution is available.

What you've proposed is still a very simple extension for a theme or plugin to add.

• Register a new block style
• Enqueue the desired CSS (including something to enforce correct aspect ratios, no cropping etc)

If neither feels right, would you have a concrete near-term direction in mind that could close

No, I don't have a concrete near-term plan for this. Especially as my efforts and time are unfortunately directed elsewhere at the moment.

I would love for core to have a native masonry layout but it is ok that some features are left to the broader plugin ecosystem until there is a canonical and clean approach to solving the issue.

I know I also sound like a broken record here but it is worth reinforcing again for others reading along that what is proposed here still is not a masonry layout so even if this landed, it wouldn't and shouldn't close #28247.

Separately from this PR - is there any plan to address the existing imageCrop: off gaps in Gallery, or is the current behaviour considered acceptable?

I'm not aware of anything at the moment.

As you note, it has been this way for forever and there are several plugin options that address the immediate need. So I think it is less of a case of this being "acceptable" and more that there are workarounds or simple enough solutions that lower the urgency for something to land in core that must be maintained in perpetuity. In other words, we have the time to wait until there is a native CSS option.

This particular CSS proposal has taken a disappointingly long time to progress but my read there is sufficient reason to remain hopeful and excited for the grid-lanes feature.

Good PR, good motivation that I share. I've used text-columns myself to achieve this, but there's really no ideal solution. Not speaking authoritatively here, but I'm personally leaning towards echoing Aki that the cleanest and most accessible core solution should be to wait for the CSS spect to accommodate this on the browser level, and leave interim solutions in plugin territory. I realise this is disappointing to hear, but it also accounts for the complexity of core maintenance that this has, and the many possible permutations the userbase of this size has.