Try using a user-specific variable for blockGap #36680
Conversation
richtabor
requested review from
ajitbohra,
ellatrix,
spacedmonkey and
TimothyBJacobs
as code owners
|
Size Change: +222 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
|
Same test, with Social Links (showing how the custom blockGap does not also add vertical spacing) |
ZebulanStanphill
added
the
[Type] Bug
|
@richtabor I think this approach works well, but an audit of all blocks will be needed if this direction is approved by the rest of the team. I honestly cannot think of a better way to handle this and have been racking my brain for the past few days. I just did a bunch of testing and it looks great. I did find the Navigation block CSS will also need to be updated: , and there may be a few more. If I find any, I will report here. |
|
Confirmed Navigation block works as expected now. |
|
This is a bit unclear to me, can you share examples of theme.json and what output do you get? |
|
The Here is an example of a Columns block with the "Block Spacing" set to |
There was a problem hiding this comment.
Thanks for exploring this @richtabor, it's a really compelling idea! It's testing well for me when applied directly to the block within the editor, but I was wondering what the expected behaviour should be in theme.json when the blockGap is set for a particular block. For example, with this PR applied, if I set the following in my theme.json for just the Columns block:
"styles": {
"blocks": {
"core/columns": {
"spacing": {
"blockGap": "6rem"
}
},
Then it results in the following styles being generated server-side:
.wp-block-columns {
--wp--style--block-gap: 6rem;
}
That results in the same visual issue where the value is also being applied to the top margin:
Should this also be --wp--style--block-gap--self?
It also looks like this change has removed Block spacing from global styles for the blocks that have opted in. For example, go to the site editor, and select the columns block:
| Missing block spacing input in global styles | The block spacing input on trunk |
|---|---|
 |
 |
Could this be related to the change in api/constants.js?
Overall, though, I quite like the addition of the new CSS variable to work around the margin issue. @ramonjd also has an idea for adding in additional CSS variables for separate axial (horizontal/vertical) controls of block spacing in #35454 — this might be a question more for that PR, but if we add the additional self CSS variable, will that mean we need to create an additional self set or row / column variables for the axial support, too? The issue in #36521 is more pressing than axial support, though, so this consideration might not be a blocker.
|
Thanks a bunch for the PR. I'm a little unclear on whether it's a good idea to add this separate value, though. Is there any way we can lower the specificity of the block gaps so the margins take effect instead? CC: @scruffian @MaggieCabrera in case they have thoughts on it from a themer perspective. |
| @@ -133,7 +133,7 @@ export default { | |||
| display: flex; | |||
| gap: ${ | |||
| hasBlockGapStylesSupport | |||
| ? 'var( --wp--style--block-gap, 0.5em )' | |||
| ? 'var(--wp--style--block-gap--self, var(--wp--style--block-gap, 0.5em))' | |||
There was a problem hiding this comment.
Should we also update flow.js, why is this only applied to flex.js
|
It's really still unclear to me how this works, If all styles are updated to be: use self variable otherwise If not defined use same variable without self. And previously when a block selected a block gap (in the sidebar), it was affecting the latter variable but now it generates the latter, it seems this won't have any impact on the behavior unless there's something I'm missing? In both situations, the applied gap will apply to that bock and all its children since that new variable has more priority anyway? |
What's happening is that the Instead, the user-generated value of So what this PR aims to do is try adding a CSS property fallback method that will allow the user-generated value to function within the block (falling back to the standard blockGap value) while not interfering with the blockGap set by the theme/Gutenberg. Otherwise, the blockGap set within the control also affects the vertical spacing applied to the block. |
The key is that in the current version of Gutenberg, the user's blockGap value is applied as an inline CSS property that the following CSS inherits (resulting in the block having the blockGap value applied to the vertical space of the block, along with the intended actual "gap". |
@jasmussen Outside of this PR, we're currently overriding the The intent behind this PR is to that CSS property used, unless there is a user-generated value, (which I named So with that markup above, the blockGap control has also set the Columns block to be 100px below the block above it: |
I am curious if axial support would also resolve this particular issue though — as long as neither CSS property would be used to apply the vertical spacing between block as |
@richtabor Oh I think I understand here, can we just update the block support do generate this instead:
|
That may work — so when a block has a custom blockGap value, the direct children will inherit that value (i.e. the column blocks within the columns block, but not the blocks within the column? |
No that solves the case for the gap not applied to the "columns" block itself but wouldn't prevent the cascade. (I think the current PR doesn't prevent the cascade either) |
|
Forget it actually, that solution only works for the "flow" layout, not "flex" ones |
|
Seems the root issue here is that we're kind of missing a "gap" property on the "flow" layouts forcing us to use styles that target its children and these styles are using the variable that is set on the child blocks instead of the parent. I don't have a solution yet but I'll keep thinking about it :) |
|
Yeah it is a tricky one to come up with an elegant solution. |
|
Would something like this work? #36521 (comment) |
Description
As reported in #36521, there's a bug with custom blockGap values overriding the margin-top applied to a block.
This proposed solution adds a CSS property
--wp--style--block-gap--selfthat is only used if a custom blockGap exists. This allows the original--wp--style--block-gapto still function properly as a top-level vertical spacing mechanism between blocks, while also allowing users to customize the blockGap of a block, without inadvertently affecting the custom value affecting that block's top-level vertical spacing.How has this been tested?
Tested with blocks that support blockGap (Buttons, Columns, Social Links, Navigation).
Screenshots
Editor, no blockGap assigned:
Front-end, no blockGap assigned:
Editor, custom blockGap:
Front-end, custom blockGap:
Types of changes
Bug fix
Checklist:
*.native.jsfiles for terms that need renaming or removal).