Margin support for Paragraph blocks is desperately needed.

[ndiego]

What problem does this address?

Paragraph blocks are fundamental to the design of any website. As we move closer towards Full Site Editing, the need for full control over paragraph margins has become increasingly apparent. In fact, theme developers (myself included) are resorting to "magic classes" to zero out, or modify, margins on blocks. Allowing themes to opt-in to paragraph margin support will provide greater flexibility and decrease the reliance on custom CSS in the theme's stylesheet and/or crude "hacks".

As a side benefit, margin support works in tandem with blockGap. With blockGap enabled, margin-top is added to every block. While this is great 90% of the time, there are instances where you would want to remove/modify this margin. Margin support for paragraphs enables this functionality. Again, no need for "magic classes" or alternative solutions.

I have chosen to focus solely on the paragraph block in this issue and linked PR, but separate PRs will be created for other block types that equally need greater dimensions support.

What is your proposed solution?

#37300 Adds margin support to paragraphs. This would be an opt-in, so theme developers would need to add settings.blocks.core/paragraph.spacing.margin.true to theme.json or use the "appearanceTools": true flag.

[bgardner]

I have wanted this for months now, and have had several scenarios in which I've had to handle margins with magic classes. Given how fundamental paragraphs are to publishing content, I would vote 100% to include support for margins.

[chthonic-ds]

I agree with this proposal in broad terms: ideally any element that inherits the blockGap margin will also offer a way to modify that margin on a case-specific basis. For example, I'm really looking forward to the day when there's an Editor-level solution to prevent an unwanted margin between a couple of full-alignment Group block siblings. For now I absolutely have to choose "hacks"—one for the front-end, one for the editor—to avoid a margin in that context.

On a practical level, my worry is enabling block-level margins will encourage layouts that are neither truly responsive or device-agnostic. Conceptually, there's tension between blockGap's don't style the element, style the element's context approach versus enabling per-element margin controls.

My hope is this can be solved more elegantly than providing multiple ways to set a margin-top value. What I'd like to see:

• A smarter blockGap. We need a way to assign different blockGap values to target relationships between sets of siblings. Currently, I've only found this feasible to achieve via custom CSS.
• Give existing blockGap time in production. Hopefully there'll be a lot of block theme-based sites going live in the months after WP 5.9 is released. Allowing time for real-world usage and associated problems to surface can help inform a more sophisticated implementation of blockGap.

[ndiego]

Conceptually, I agree with everything you said @chthonic-ds. My argument for margin control is that there will always be designs that necessitate control beyond anything blockGap can and should provide. This change allows users to stop writing custom CSS and design directly in the Editor, which is a true joy.

On the topic of blockGap, it still needs a lot of work, but it's very promising and I look forward to the day when custom margin settings are only needed on a handful of design elements throughout a website. But we are not even close to that point yet. Allowing margin control to be opt-in for those that want it is harmless in my opinion. It gives people choice, and that's what's awesome about WordPress!