Add a selection of preset spacing values to supplement/replace custom padding/margin options

[cbirdsong]

What problem does this address?

Spacing quickly becomes inconsistent across a larger site with extensive use of the custom padding/margin options in Gutenberg. It's very difficult to keep a design feeling cohesive if every editor has to manually apply the same padding value when adding a columns block. Additionally, because these custom values are output as inline styles it then becomes extremely difficult to revise this if you decide you'd really like some more padding in your columns blocks.

What is your proposed solution?

The font size system provides a decent blueprint. On the back end, users should be able to pick from a list of preset options in addition to the custom margin/padding field, and theme authors should be able to register their own presets and disable the custom field entirely. On the front end, these presets should be output as classes like has-spacing-small, avoiding the problems associated with inline styles.

[carolinan]

Hi!
I believe that one of the purposes of the theme.json setting file is to mitigate this issue.
I mean that that is how theme authors are registering their presets and also disable the editor controls. Did you explore and try theme.json?
You did not include any background information, so I don't know what you have already tried.

[cbirdsong]

I have played around with it a bit using the Blockbase theme. As best I can tell there's no way to define a range of spacing sizes and get rid of the custom option completely like you can with font sizing? Something like this is what I have in mind:

(Extremely rough mockup made by dragging things around in the inspector, a range slider might be better UX?)

[carolinan]

No, but you could disable the control and have block styles and it would work similarly.

[cbirdsong]

Yeah, that is least bad option available and what I’ve gone with. However, that leaves the user without any control over the amount of padding¹ and there are obviously situations where you might want to allow that. The two options the editor provides right now are “no control” and “do whatever” and neither are a very good fit for producing high-quality websites.

A sampling of workarounds I’ve come up with to deal with the lack of control when disabling custom padding amounts:

• Registering a transparent “color” to apply the has-background class and add some padding without changing anything else visually, which is obviously a massive hack. It sometimes causes issues when interacting with CSS that expects has-background to actually mean the item has a background, and I cringe every time I explain to a client/editor that the way to add a little padding is to select the empty spot in the background color pane.
• Filtering the output of the columns block and adding a class based on the number of child columns (has-3-columns, etc). The theme CSS uses that to apply a more appropriate amount of padding. This helps, but there are still situations where it’s not a good fit and actual user control would be beneficial.

Problems I’ve encountered when allowing custom padding amounts:

• Padding is not likely to be applied consistently since the editor is probably not a designer and wouldn’t understand that consistency is important for a design to feel cohesive.
• If the user does apply the same few padding values consistently it’s extremely difficult to update them when changing themes or otherwise revising the design, since they are stored as inline styles scattered all throughout the content.
• It’s impossible to adjust these padding values for different screen sizes, either by using complex calc(1rem + 0.25vw)-style values or through media queries.

The presets used for font size sit right in the middle of these two approaches and is an elegant solution to the problem. Content editors can choose a set of preset sizes, which reduce the need for entering custom values and can easily move between themes without causing design issues. Theme authors can then add to those presets and style them with whatever CSS they’d like, and can optionally disable the custom value field if it’s not a good fit for the goals of the theme.

Footnotes

1. I’ve used padding throughout my examples since that’s more common in the shipping version of the editor, but any custom margin or gap spacing options would run into the same issues. ↩

[jasondilworth56]

It's well documented around the web that inline styles should very much be the exception rather than the rule when aiming at consistent design and layout. This would be a good step in that direction 👍

[adamgreenough]

+1 on this. Spacing and typography are fundamentals and should be a higher priority than new features. Spacing is by far my biggest issue working on new Gutenberg themes and a more versatile and stylesheet-controlled way as proposed by OP would be ideal. The spacer block is not enough and I am currently working with custom classes for the additional classes option which is half way there, but a control would be great.

[cbirdsong]

Moving discussion of this to #39371.