Size Change: +611 B (0%)

Total Size: 1.04 MB

_{compressed-size-action}

Based on feedback in #33812 (comment), I've refactored this to use a single CSS variable (--wp--style--block-gap) and removed the split horizontal / vertical values and controls (we can always explore this further in follow-ups). I've also updated the naming of the support to blockGap and customBlockGap for consistency with that PR.

Next up, I'll look into server-rendering the value instead of storing in inline styles. Just a note here that this is still in progress, I'll update the PR description to match the current state of things later on today.

Added in server-rendering in 3fea1eb along with skipping the serialization of the blockGap value in post content, which seems like it's going to work to get around issues with storing CSS variables in post content. So it seems promising so far! There are some outstanding issues with the approach I've gone with, which I'll look at cleaning up tomorrow along with adding more tests.

Just noticed another bug to do with the difference between rendering within the editor and rendering server-side: it appears that the Edit component's inline styles aren't being rendered in the site editor. I'll take a look at what's going on.

inline styles aren't being rendered in the site editor.

This issue is to do with rendering the gap support styles within the post-content block, which takes the rendered markup from the API response for the post, and renders it in a RawHTML component. In this context, the styles generated and rendered in wp_footer are never included, so the block-level styling isn't preserved:

Gap setting while editing post	The post rendered in a post-content block

An option to explore is to render the style tag in situ, instead of in the footer. I'll take a look at that tomorrow.

I've had a go at server-rendering an inline style in 842bbfe to resolve the issue of rendering in the post-content block, and it seems to simplify things a bit, too. It seems promising to me so far, but since it's regex based, it might do with some testing. I'll keep chipping away tomorrow.

I've updated this PR to tweak the regex slightly and add in some additional PHP tests. I've also removed gap from the function that applies the spacing support for dynamic blocks, as this gets handled anyway by the render_block callback for all blocks.

I think once #33812 lands, this PR should be in a good place for reviews / testing. I'll continue to update this PR if and when that PR lands to remove the duplication that gets this PR working.

Thanks for testing @stacimc! I've raised a PR to look into the styling regression in #34189. Once that's resolved, I'll give this a rebase and we can see about getting a final test/review.

The only slightly odd things I noticed are just Buttons-specific stuff and would be handled when adding the support to that block

I imagine there'll be a few wrinkles for implementing the gap support for particular blocks, but hopefully with the CSS variable approach, this will free us up to address the concerns of the individual blocks on their own PRs, like you suggest 🙂

Also tested according to instructions. Aside from the extra margins on buttons, which @stacimc already highlighted, it's working well for me. NICE!

I also tried it out on other blocks as well. Here's the gallery block:

It's going to be very useful for such patterns. Thank you!

Was there a specific thought process behind making the name be blockGap versus customBlockGap like the other related spacing properties? It seems to make the most sense to keep the naming convention as streamlined as possible to avoid confusion.

Thanks for the question @fwazeter, it looks like you've probably already read the linked issue, but for completeness sake — according to the theme.json v2 issue the current long-term plan appears to be to remove the custom prefix from those properties where the word "custom" doesn't have semantic meaning (including for customPadding and customMargin). By ensuring that the blockGap property starts out without the prefix, we can avoid having to migrate it further down the track. So hopefully we'll be able to get that consistency in there across the properties by WP 5.9.

It appears that Safari doesn't re-render / recalculate grid or flex layouts when the gap value changes on its own. It needs another CSS property to change as well in order to trigger the layout to be updated.

Indeed, I was testing on Safari, what a weird bug. Curious to know if they're aware of it :)
I agree that it'd be good if we find a hack for it temporarily. I don't consider it a blocker to get this moving forward though.

Thanks @youknowriad, I appreciate the review and feedback! Since this PR adds in the block support without switching it on anywhere, I'll merge it in now and I can look at enhancements and a fix for Safari in follow-ups. 🙇