Use button block appender on group block

[talldan]

Description

Adds the button appender from #14241 to the group block.

How has this been tested?

• Manual testing
• E2E test

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[talldan]

I plan to write some tests for this.

Some initial observations:

• It feels like the button should be focused when adding the group block.
• It quickly gets confusing if you nest multiple group blocks (probably not a major use case at this point, but something to think about).
• When using the arrow keys to navigate blocks, the appender is not part of the navigation.

[youknowriad]

Thanks @talldan for the quick PR, in testing I wonder if the appender should be hidden if the block is unselected and already contain items, what do people think? the condition could be

( isSelected || ! hasChildren ) && <Appender />

What do you think @mapk @jasmussen @mtias

[aduth]

Thanks @talldan for the quick PR, in testing I wonder if the appender should be hidden if the block is unselected and already contain items, what do people think? the condition could be

( isSelected || ! hasChildren ) && <Appender />

What do you think @mapk @jasmussen @mtias

This needs a decision. I'd tend to agree with @youknowriad that I was surprised by how out-of-place the button inserter feels after having inserted an "initial" block (i.e. once it's no longer empty).

[kjellr]

Yeah, I think it makes sense to hide it under those conditions. That helps preserve the 1:1 visual relationship to the front end. 👍

[aduth]

Related: #14241 (comment)

[aduth]

Yeah, I think it makes sense to hide it under those conditions. That helps preserve the 1:1 visual relationship to the front end. 👍

Hmm, I've been experimenting with this. I can't quite put a finger on it, but something about it feels not quite right. It's notably hard to follow when and why the appender is visible if the Group does not have a background assigned, or there are Group blocks within or adjacent to one another (similar observation as #14943 (comment)).

You can give it a try at: http://gutenberg.run/14966
Branch: #14966

[jasmussen]

Great thoughts, thanks for trying that branch, Andrew, and what is this wonderful new gutenberg.run thing!? I love it. Here's what i see:

My very first instinct is that as soon as you've inserted a single block inside the group, we no longer need to use the generic appender for that block. That interface only feels necessary for the setup state. After that, the same interface that every other block uses — press enter or use the sibling inserter, feels sufficient to me. We already have so many many (+) buttons all over the place, we really need to be careful in adding more of them.

What do you think?

[youknowriad]

I think we need a padding on the bottom if there's a background applied

[talldan]

I think we need a padding on the bottom if there's a background applied

Hmm, that's trickier than it looks. Might need some help from @jasmussen on this, if you have time.

[jasmussen]

Hmm, that's trickier than it looks. Might need some help from @jasmussen on this, if you have time.

Oh that's interesting indeed. Here's what I see:

I recall us very recently removing the background color on this one, cc: @kjellr, maybe that wasn't a great idea.

Okay, made a patch — I can push to this branch if you like, but didn't want to commandeer it because the change I'm proposing is a little opinionated, so feel free to try it out first, otherwise let me know and I'll push:

diff --git a/assets/stylesheets/_colors.scss b/assets/stylesheets/_colors.scss
index 3575248e3..e11ee062f 100644
--- a/assets/stylesheets/_colors.scss
+++ b/assets/stylesheets/_colors.scss
@@ -44,6 +44,7 @@ $dark-opacity-light-400: rgba(#95959c, 0.2);
 $dark-opacity-light-300: rgba(#829493, 0.15);
 $dark-opacity-light-200: rgba(#8b8b96, 0.1);
 $dark-opacity-light-100: rgba(#747474, 0.05);
+$dark-opacity-background-fill: rgba($dark-gray-900, 0.8);
 
 // Light opacities, for use with dark themes.
 $light-opacity-900: rgba($white, 1);
@@ -64,6 +65,7 @@ $light-opacity-light-400: rgba($white, 0.25);
 $light-opacity-light-300: rgba($white, 0.2);
 $light-opacity-light-200: rgba($white, 0.15);
 $light-opacity-light-100: rgba($white, 0.1);
+$light-opacity-background-fill: rgba($white, 0.8);
 
 // Additional colors.
 // Some are from https://make.wordpress.org/design/handbook/foundations/colors/.
diff --git a/packages/block-editor/src/components/block-list-appender/style.scss b/packages/block-editor/src/components/block-list-appender/style.scss
index 026e899db..e1725aa00 100644
--- a/packages/block-editor/src/components/block-list-appender/style.scss
+++ b/packages/block-editor/src/components/block-list-appender/style.scss
@@ -1,5 +1,11 @@
 .block-list-appender {
 	margin: $block-padding;
+
+	// Add additional margin to the appender when inside a group with a background color.
+	// If changing this, be sure to sync up with group/editor.scss line 13.
+	.has-background & {
+		margin: ($block-padding*2 + $block-spacing) $block-padding;
+	}
 }
 
 .block-list-appender > .block-editor-inserter {
diff --git a/packages/block-editor/src/components/button-block-appender/style.scss b/packages/block-editor/src/components/button-block-appender/style.scss
index 5c045aee8..f153a2353 100644
--- a/packages/block-editor/src/components/button-block-appender/style.scss
+++ b/packages/block-editor/src/components/button-block-appender/style.scss
@@ -7,7 +7,7 @@
 	outline: $border-width dashed $dark-gray-150;
 	width: 100%;
 	color: $dark-gray-500;
-	background: $dark-opacity-light-100;
+	background: $light-opacity-background-fill;
 
 	&:hover,
 	&:focus {
@@ -22,7 +22,7 @@
 
 	// Use opacity to work in various editor styles
 	.is-dark-theme & {
-		background: $light-opacity-light-100;
+		background: $dark-opacity-background-fill;
 		color: $light-gray-100;
 
 		&:hover,

Now it looks like this:

or this in a dark theme:

This actually changes the background color of the generic appender to be way more opaque everywhere it's used. But this is necessary since it can show up on any color background, I feel (another Kjell sanity check would be good here).

It also adds additional margins to the appender when seen in context of the has-background, because the group itself has special rules to cancel those margins out. I'm not sure this is great, but hence the patch. Lay thoughts on me.

[kjellr]

@jasmussen Yep, I think that's the right move. We'd probably want to annotate those new background fill variables to make it clear why they exist.

I have some incredibly minor adjustments to the color values to recommend. I think these match the placeholder backgrounds just a little more than what you have currently:

Light backgrounds: rgba($light-gray-300, 0.8);

Dark backgrounds: rgba($dark-gray-700, 0.7)

Also, I think your patch has the new colors incorrectly swapped. Based on the code comments in _colors.scss, I believe we'd want to use $dark-opacity-background-fill for the light backgrounds, and $light-opacity-background-fill for the dark backgrounds.

[jasmussen]

Those screens look pretty good to me. I'm out for the day, but if you like, feel free to adjust that patch and push it up with the changes you suggested!

[jasmussen]

Would the idea be that the default/paragraph appender is used instead after the first block is inserted?

Sort of, yes. Basically I imagine the behavior to be the same as it is in any other current nested block, like Media & Text or Columns. I.e. in nested contexts, there isn't actually any trailing appender unless the last block is a not-text-block:

[talldan]

Thanks @jasmussen, I've pushed some changes to the branch. The way it works now is:

• The button appender is only present when the group block is initially added. It's visible both when the block is and isn't selected.
• After the first block is added the default appender is used instead. It'll work the same way as a column in that the default appender is visible after a non-paragraph block.

Let me know if that seems the right behaviour.

[jasmussen]

Love it, thank you, this is a vast improvement. Here's a GIF:

This GIF also highlights a small challenge with this approach. But that challenge is not specific to this branch, and therefore something we can look at separately. But still perhaps something to think about. It's this:

Even though there's only a image placeholder in the group, the fact that the empty appender sits below means there's empty space where it feels like there shouldn't be.

This is already the case with the columns block too:

And even Media & Text — the button in the right column is supposed to be vertically centered but is offset by the empty appender:

The solution here is, separate from this branch (and to be clear, I think it's now good to go 👍 👍), explore a way for that trailing text appender to behave in a less intrusive way. I could swear there was already a ticket about this, I know that @mapk has mentioned the off-center issue, and I feel like @kjellr has thought about empty paragraphs too.

A couple of strawman solution ideas:

1. Don't ever show the trailing appender at the end of a nested block list.
2. Only show the trailing appender at the end of nested block list if a block nested block list is selected. I.e. in the examples shown above, you have to click the image first before the appender is visible.

I like option 1 because it is how editors traditionally work: the way you insert a linebreak is you select the place you want a linebreak after, and press Enter. In this case, you'd select the image and presse Enter, and you'd have your empty paragraph. Perhaps combined with #10051 this would make for a nice separate iteration.

But it's also worth noting that this suggestion has been controversial in the past, because while this is an editor, it is also a "block editor", and users don't always assume that the behavior they're used to from traditional editors will work here. But much of that controversy was mitigated by improvements to the sibling inserter, which will ALSO work here. So I think it may be worth looking at.

[talldan]

Thanks for the help @jasmussen—hopefully this is good to go then pending a code review.

I like that it wasn't particularly complicated to implement in the Group block. There might still be room for improvement code-wise around how this kind of appender can be implemented for block builders, but I think this is ok as a first step.

Just a note that I'll be away on vacation until the end of the month (I probably should have handed this over earlier, sorry about that).

[jasmussen]

hopefully this is good to go then pending a code review.

Yes, I would say so!

[aduth]

I wouldn't mind to have seen this function be inlined.

Alternatively (separately), I would like to see as proposed in #14241 (comment) with createElement being used with renderAppender so this could be come:

renderAppender={ ! hasInnerBlocks && InnerBlocks.ButtonBlockAppender }

[talldan]

Thanks for the review. I'll follow up with a PR that tries out createElement. The only concern I'd have is lack of consistency with other render props, but that would only be an issue if renderAppender ever took arguments.

[talldan]

PR is here - #15259

[irishetcher]

The appender indicator is a much welcome addition. An improvement to it would be to be the ability to drag a block into the enclosing element and have it take the appenders place. As it is you still need to add a random block before you can drag in another block.

Also this highlights the need for a way to multi select and drag several block to another location, apart from the copy/cut/paste option. Include option/drag here for several selected blocks to duplicate to another location. Probably a separate PR.

[kjellr]

An improvement to it would be to be the ability to drag a block into the enclosing element and have it take the appenders place. As it is you still need to add a random block before you can drag in another block.

Thanks @irishetcher. The fact that you can't drop into the area when the appender is present is a bug, and is fixed in #15702. There's also discussion there around allowing people to drop directly onto the appender itself. Hopefully we'll see a PR for that soon. 👍