[Resolved] Bottom margin not removed from last block if it is custom HTML

[Gabriel]

I found the following style in GeneratePress:

.entry-content > [class*="wp-block-"]:not(:last-child) {
    margin-bottom: 1em;
}

I guess its purpose is to add a margin after all blocks on the page except the last one. But if you create a custom HTML block with the content <script>/* HELLO WORLD!*/</script> at the bottom of the page you will have a last block without a “wp-block-” class and margin-bottom is set on the block above.

Is this a bug or a feature?

[David]

Hi there,

your understanding of that CSS rules purpose is correct. But it does have instances where it fails, such as using Custom HTML at the end of a post.

Personally i try to avoid adding scripts in the post content. And instead use a Hook Element to add that script to the wp_footer which is the ‘correct’ place for scripts.

[Gabriel]

In our case it is a analytics snippets that should be added to specific pages. I made it as a reusable block so that I do not have to hard code any pages into it. Our editors add forms from our CRM this way so they are already used to the workflow.

We can work around it by not adding the script to the bottom but it is a little inconvenient. Any reason for that you are not selecting all children instead of just wp-block- instances? Something like this: .entry-content > *:not(:last-child)

[David]

If its in a reusable block, then wrap the <script> tag in <div> with a block a bogus class eg.

<div class="wp-block-script">
<script>...</script>
</div>

That should overcome the issue.

In the past with Classic editor the margin was stripped from the last P tag.
When Blocks came along they introduced a whole layer of complication with core styles. ie. some blocks had margins others did not.

It’s the joys of being a theme developer when WP core decides to introduce theme styles at a core level, trying to maintain legacy styles is a pain. In 99% of cases it just works, but there will always be a few exceptions.

[Gabriel]

This would fix it for the cases where the script is in a reusable block only. We also have scripts that are created on the fly by editors in the CRM system. Now it seems that our layout only works correctly by accident, because the scripts are usually placed in a group or column block.

I understand that you make your own design decisions but from my perspective this is if not a bug at least a quirk of GP that does not exist in TwentyTwenty from WordPress Core.

TwentyTwenty has this CSS that applies to all direct children of entry-content instead of just some specific blocks:

[Gabriel]

.entry-content > * {
    margin-bottom: 1.25em;
}

.entry-content > *:last-child {
    margin-bottom: 0;
}

Got error “Are you sure you wanted to do that” in previous post. Worked after moving the code snippet to a separate post.

[David]

When Guteneberg first launched in core, WP included wp-block styles that were more specific then the wildcard * selectors the theme historically used ( like those in TwentyTwenty ).

Which caused an issue. Anyone migrating from Classic editor to Blocks would experience a change in their spacing. Reluctantly, but in order to maintain those styles we had to implement more specific CSS to overcome the problem.

TwentyTwenty never had legacies to deal with, and as a single purpose theme it doesn’t have the dynamic CSS requirements that GP does.

Now the gutenberg has stablisied a little, and some of the styles have been changed, we may be able to revisit that.
Although that too is tricky decision. As core does have the wonderful habit of changing core block styles on updates.

[Gabriel]

OK then I understand. Thanks for answering my questions.

[David]

You’re welcome – sorry for the frustration it has caused.

[Author]

Posts