Adjust paragraph block spacing to use standardised variables

[getdave]

Description

Please see this discussion on the Section Block for context.

Essentially we need to ensure that all Blocks which apply padding when they have a background set have the same values set. To do this we need to create some new variables that match up with what is currently set on the paragraph Block.

Adjusting the paragraph Block values seems fraught with danger so we construct new vars to provide new vars which match the existing values.

Testing

To test just confirm that the values for padding on the <p class="wp-block-paragraph... have the same values as on master (ie: padding: 20px 30px).

[jasmussen]

Thanks for creating this PR!

I love where you're coming from, and I think the instinct is right. But I think we should remember to separate UI from content. The variables you leverage are firmly UI values.

Perhaps we also don't need new variables just for the padding in paragraphs and section blocks, maybe we can just do this?

Before:

p.has-background {
	padding: 20px 30px;
}

After:

p.has-background {
	padding: $grid-size-large ($grid-size-large * 2);
}

That maps to padding: 16px 32px, but that seems fine to me. Alternately if we consider the 20/30px values backcompat, we could do this:

p.has-background {
	padding: ($grid-size-small * 5) ($grid-size-small * 8);
}

That gets us only 2px from the 30, but that should be close enough.

[getdave]

@jasmussen Really appreciate your feedback here.

Thanks for creating this PR!

No problem 👍

But I think we should remember to separate UI from content. The variables you leverage are firmly UI values.

I didn't quite follow this. I am certainly considering them UI values. They are a core part of the UI which are needed elsewhere but are not captured in a variable. Therefore they represent a risk in the codebase if many disparate locations rely on them remaining consistent.

Perhaps we also don't need new variables just for the padding in paragraphs and section blocks

Ideally not. However, as you suggest for backwards compatibility reasons I'd be pretty nervous about changing these values. Who knows how many 3rd party Blocks rely on these? There are probably also locations within Gutenberg Core itself which rely on them remaining "as is".

only 2px from the 30, but that should be close enough.

Knowing the amount of work it took to get Section alignments working, I am not convinced that we can consider 2px not to be a problem. That's enough to make a layout look pretty broken.

I'm still not 100% sure why we can't introduce a new variable. A quick search in the Block library finds 4-5 uses of 20px and 2-3 of 30px. Maybe this isn't a sufficient threshold to make this a problem, but what if these use cases are important?

Not trying to be awkward here, just wanting to ensure we

1. Shoot for 100% accuracy
2. Ensure consistency
3. Reduce risk

If we're not convinced then I'd be tempted to leave "as is" rather than reopen the Section block alignment again.

[jasmussen]

I didn't quite follow this. I am certainly considering them UI values. They are a core part of the UI which are needed elsewhere but are not captured in a variable. Therefore they represent a risk in the codebase if many disparate locations rely on them remaining consistent.

I was a bit unclear here. By UI I'm referring to the editor — the left navigation, the top editor bar, the right sidebar, but not the editing canvas, which I'm referring to as "content".

Which actually means my own suggestion to use the $grid-size variable is a bad idea, and we can totally introduce new variables for this, so thanks for taking me to task.

But $block-padding is also editor UI, because it doesn't (and shouldn't) affect the footprint of a block, and it's UI that we draw to manipulate those blocks regardless of what theme or editor style you are using. For themes that do well in making the editing canvas look like the frontend theme through editor styles, you will very likely have situations where those default block paddings are heavily customized by said theme. That fact isn't changed by how the padding variables are put together, but simply keeping them separate from the editor specific variables feels like general code-quality and cleanliness. Also, if I can ever ship #14407, $block-spacing will hopefully be retired. In fact we may want to rename $block-padding to be something that's prefixed with editor or something, like $editor-ui__block-padding

So to summarize:

• You were right, new variables are fine
• Let's try and avoid using $block-padding and $block-spacing for anything but what we consider "the editor"

On a final nitpicky note, thanks for your patience — do we have some sort of BEM pattern we can follow for the variables? BEM expert @gziolo any thoughts? These feel a little long and exotic to me:

$block-with-background-v-padding
$block-with-background-h-padding

Maybe this $editor-style__background-padding-v and $editor-style__background-padding-h?

You can then keep the values 20px and 30px directly.

[gziolo]

On a final nitpicky note, thanks for your patience — do we have some sort of BEM pattern we can follow for the variables? BEM expert @gziolo any thoughts? These feel a little long and exotic to me:

$block-with-background-v-padding
$block-with-background-h-padding

Maybe this $editor-style__background-padding-v and $editor-style__background-padding-h?

I personally don't have any issues with long names. v or h might be hard to read for those who look at those names for the first time. I don't know if there are any coding guidelines for SCSS variables but I see that the general pattern is $my-variable-name. If you are seeking for BEM experts @aduth is your friend 😄

[getdave]

Thanks @gziolo. I've updated the variables. Unless @aduth objects I'd like to get this merged.

Could someone approve this?

[gziolo]

I've updated the variables.

Did you push your changes or is it GitHub's cache issue?

[aduth]

I don't know if there are any coding guidelines for SCSS variables but I see that the general pattern is $my-variable-name. If you are seeking for BEM experts @aduth is your friend 😄

I too am not aware of any guidelines around how to name variables. Nor do I feel particularly strongly about any.

[getdave]

I've updated the variables.

Did you push your changes or is it GitHub's cache issue?

Caching 41286af

@aduth thanks for confirming. Could you @gziolo or @youknowriad approve this PR then? Much appreciated.

[gziolo]

No rules 🤷‍♂️

🚢