Gallery: Opt-in to axial (column/row) block spacing controls

[andrewserong]

What?

Fixes: #41174

This PR opts-in to separate column / row (or horizontal / vertical) controls for the spacing between images in the Gallery block. This unlocks layouts like the following, where depending on the design, folks might like to have a different horizontal versus vertical gap between images:

Why?

In #41125 we added in the technical capability for the gallery block to support split horizontal / vertical values. That PR was merged primarily as a bug fix — this PR now opts-in to the controls so that the feature is available in the UI.

How?

• Opt the Gallery block in to split horizontal / vertical controls in the block.json file.

Testing Instructions

1. In a theme that opts-in to spacing.blockGap, go to add a gallery block and add a few images.
2. In the Dimensions controls, set the grouped block spacing to a value and make sure it works.
3. Click the button to Unlink sides.
4. Adjust the vertical and horizontal values and ensure that the spacing looks correct in the editor and on the front end of the site.

Screenshots or screencast

[ramonjd]

This is working well for block themes 🎉 in both the editor and the frontend

For classic themes I'm seeing that the layout gap default value is overwriting the gap value:

Where have we see that before 😄 ?

In classic themes I'm seeing this in the footer:

		<style> .wp-block-gallery-2{ --wp--style--unstable-gallery-gap: 154px; gap: 208px 154px}</style><style>.wp-container-3 {display: flex;gap: 0.5em;flex-wrap: wrap;align-items: center;}.wp-container-3 > * { margin: 0; }</style>

For block themes, the layout styles are in the header, but the gallery gap css is in the footer, so it overwrites gap.

Maybe something to test further in #41015 too @glendaviesnz

[ramonjd]

Oh, I forgot to ask whether it matters since classic themes might not opt-in to blockGap in general anyway?

Might affect copy/pasted block content though.

[andrewserong]

Thanks for testing!

Oh, I forgot to ask whether it matters since classic themes might not opt-in to blockGap in general anyway?

I think I'd lean toward it not really mattering too much for classic themes because they can't opt-in to blockGap. But yes, probably something to look closer at in testing #41015.

[glendaviesnz]

Oh, I forgot to ask whether it matters since classic themes might not opt-in to blockGap in general anyway?

This is the same on trunk at the moment, ie. if you add a gallery to a block theme and set the gap, then switch to a non-block theme, the gap on frontend reverts back to the 0.5em gap default ... so I don't think we need to worry about it as part of this PR.

[glendaviesnz]

I wonder if there are any implications with --wp--style--gallery-gap-default which was added with the intention of allowing themes to set default to something other than 0.5em. It will break the column width calculations if it was set to column and row values. I don't think it needs to affect this PR, and I wonder if theme.json would be the way to set default row and column values, rather than trying to extend the usage of that css var?

[andrewserong]

I wonder if theme.json would be the way to set default row and column values

In the longer-term, ideally yes, it'd be great to be able to set default values there (particularly when we come up with a solution for #39789 where we could do it at the gallery level within theme.json). Semi-related: there's also an open issue to look at supporting shorthand values in padding in global styles (#40132). If we wind up implementing that, we could do it for blockGap, too.

[glendaviesnz]

Tested well for me. Worked as expected for block themes, and non-block themes continued to fall back to the gap default.

[andrewserong]

Thanks Glen! Since it's nearly the end of the week for me, just to be safe, I'll leave this open until Monday and merge then if there aren't any objections.