button-block-appender css selectors should not target group block specifically.

[wwdes]

Description

I will use this post to document all issues that I find related to styles for ButtonBlockAppender and even the normal BlockListAppender.

---

I suspect that several styles related to the ButtonBlockAppender component are erroneously selecting group block. This is a problem because the component is not exclusive to the group block.

In packages/block-editor/src/components/button-block-appender/content.scss at line 37 and 38:

.block-editor-block-list__block:not(.is-selected) > .is-layout-constrained.wp-block-group__inner-container > &,
.block-editor-block-list__block:not(.is-selected) > .is-layout-flow.wp-block-group__inner-container > & {

The incorrect selector is .wp-block-group__inner-container, when it should be a block-agnostic selector, namely the .block-editor-block-list__layout class that is applied to the inner containers automatically. Because of this, the styles are not applied to ButtonBlockAppender when a custom block opts-in to use it along with the common block JSX structure:

const blockProps = useBlockProps();
const innerBlocksProps = useInnerBlocksProps(
	{ className: 'wp-block-my-block__inner-container' },
	{
		renderAppender: InnerBlocks.ButtonBlockAppender,
	}
);

return (
	<TagName { ...blockProps }>
		<div { ...innerBlocksProps } />
	</TagName>
)

In packages/block-library/src/group/editor.scss are also several styles that improve the appearance of ButtonBlockAppender in different layout configurations for the group block. These styles would be just as useful for custom blocks that opt-in for the layout support controls, specifically when allowSwitching is set to true which enables the same layout capabilities as the group block. I believe that these styles should be moved from the group block, in to the button-block-appender's css but with corrected selectors.

Step-by-step reproduction instructions

Create a block with the common pattern as shown above. Set allowSwitching to true in supports>layout in block.json.

Screenshots, screen recording, code snippet

No response

Environment info

Gutenberg 20.8.0

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[t-hamano]

Thanks for the report. Looking at the PRs below, are the current selectors intentional?

• Try: Add a clickable Group setup state #40664
• Group: Fix click-first state #43513

[wwdes]

Hello. I edited my post with some new findings.

Looking at the PRs below, are the current selectors intentional?

• Try: Add a clickable Group setup state #40664
• Group: Fix click-first state #43513

I looked in to some history and came to following:

(Aug 15, 2022) #40664 introduces the click-state for the appender, but the changes are implemented for the group block specifically.

(Aug 26, 2022) #43513 aims to add fixes to click state. There is a consensus that the styles should be block-agnostic and are moved from packages/block-library/src/group/editor.scss to packages/block-editor/src/components/button-block-appender/style.scss

(Oct 5, 2022) #44660 adds more block-agnostic selectors to packages/block-editor/src/components/button-block-appender/style.scss to make sure styles are applied to constrained layouts.

(Oct 18, 2022) #45050 changes the selectors to target group blocks specifically, to address some problems due to nesting group blocks. PR overlooks ButtonBlockAppender’s non-exclusivity to group blocks.

(Nov 16, 2023) #56130 makes some selector updates by adding layout classes for "legacy" inner containers. PR is also unaware that ButtonBlockAppender is non-exclusivie to group blocks.

My conclusion is that these PRs are mostly made without regard for the fact that ButtonBlockAppender can be used in custom blocks. I also do not like that inner containers are considered as "legacy". They may be outpaced within the group block because it is not needed there, but there will always be a need for inner containers for some applications in custom blocks. In fact if inner containers would not be possible anymore, it would seriously limit what is possible to develop with custom blocks.

I personally like the styles that were introduces by 40664, and think they should be standard by default to any block that wants to use ButtonBlockAppender. If any deviation from the standard styles is preferred, it should be implemented within specific blocks that require it. Alternatively they can use the default appender or develop a custom one.

I also saw some other problems with the ButtonBlockAppender styles on the group block it self. When it's layout is configured as Vertical stack, it does not seem to inherit vertical alignment for the block's content, which is prevalent when the block has some minHeight set that is above the height of the appender styles. I will look more in to this later in case it can be patched up together with everything else that i mentioned.

[wwdes]

Looking for feedback on following css in packages/block-library/src/group/editor.scss:

.wp-block-group {
	// Ensure not rendering outside the element
	// as -1px causes overflow-x scrollbars
	.block-editor-block-list__insertion-point {
		left: 0;
		right: 0;
	}
}

This was introduced in #13964 and I suspect it no longer does anything because elements with .block-editor-block-list__insertion-point class are (as far as i can see) no longer within their corresponding blocks but rather are overlayed in popovers. If someone can confirm this then this can be cleaned up.

[wwdes]

Another regression in appender styles.
#50826 introduced visual cue when dragging blocks over empty blocks.
It does not work with normal "constrained" block layouts because of how click-state styles from #40664 hide the appender. However, there is an outdated counter-measure in packages/block-editor/src/components/button-block-appender/content.scss:

		&.is-drag-over {
			&::after {
				border: none;
			}

			.block-editor-inserter {
				visibility: visible;
			}
		}

It does not work because appender is hidden with opacity prop, not visibility. So changing it to opacity: 1; will make it work as intended.