Styling issues with Appenders

[olafleur-godaddy]

Description

After #36605 , some of the appenders in CoBlocks are now behaving very strangely.

For example, here is what happens in the FAQ block (Custom Appender) :

Before (12.0.1)

After (Nightly)

Here is the source code if there is something in the implementation that could help you figure out the issue : https://github.com/godaddy-wordpress/coblocks/blob/master/src/blocks/faq/appender.js

It also happens in other blocks that have a Custom Appender or InnerBlocks.ButtonBlockAppender (like the Pricing Table block) : https://github.com/godaddy-wordpress/coblocks/blob/master/src/blocks/pricing-table/pricing-table-item/edit.js#L114

It's as if some of the CSS classes are overwritten and not applied.

Any idea if this is the expected behaviour going forward or it is a regression that we should expect to get fixed?

Step-by-step reproduction instructions

1. Start WordPress 5.8.2 with Gutenberg nightly installed
2. Install CoBlocks
3. Create a FAQ block
4. See the result :)

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 5.8.2
• Gutenberg Nightly
• Twenty-Twenty-One Theme

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

[Mamaduka]

Cc @jasmussen.

[jasmussen]

Thanks for the ticket, thanks for the ping! This issue is the result of #36605, which intentionally changed all the appenders to be overlays, fixed to the bottom right corner:

This is in contrast to before, where inline appenders would cause layout shifting when selecting an appender.

I think there are two things we can/should do here. One quick interim fix is this:

[data-type^=coblocks].is-selected .block-list-appender {
	display: block;
}

That restores the previous behavior for coblocks:

It's worth reiterating that the layout shifts that happen as the appenders appear in the canvas have been problematic, and will likely be problematic for coblocks as well, so it might be worth exploring other solutions.

That being said, it's likely there will always be some edgecases where an appender that appears directly in the DOM is useful. This is, for example, the case with the navigation block as outlined in this PR. In that vein, I wonder if we can do some tweaking to the appender to force it to output inline in the canvas in certain cases. For example, whenever the appender is the small black plus, it should be an overlay, but perhaps whenever the block has a white background and black border, it could appear inline? This might also let us tweak this edgecase for the group and columns blocks:

.block-editor-block-list__block .block-list-appender:only-child {
    position: relative;
    right: auto;
    align-self: center;
    list-style: none;
    line-height: inherit;
}

CC: @youknowriad

[youknowriad]

Is coblocks using renderAppender prop or the built-in appender. Sounds like the former based on the screenshot but I can be wrong. Anyway, if it's the former, it seems a good fix here would be to only target the "default" appender with the "fixed" style and leave the component itself unopionated about its position.

[olafleur-godaddy]

Yeah, we are using the renderAppender, but I'm not quite sure what you mean by
"only target the "default" appender with the "fixed" style and leave the component itself unopionated about its position"

[talldan]

only target the "default" appender with the "fixed" style and leave the component itself unopionated about its position

@olafleur-godaddy I think this is referring to the fix that could be made in Gutenberg. That the changes in #36605 could only apply to the default version of the appender and not other appenders.

@youknowriad can correct me if I'm wrong.

[olafleur-godaddy]

So, is my understanding correct that we should expect a fix to Gutenberg where the changes of #36605 will be modified to be only applied to the default version of the appender @youknowriad ?
That way, it would solve our issue?

[ralucaStan]

For example, whenever the appender is the small black plus, it should be an overlay, but perhaps whenever the block has a white background and black border, it could appear inline?

Restricting the change from 36605 only to the small black plus would be ideal, because this overlay approach also affects custom buttons added by the user, which are usually bigger. The white background and black border buttons are usually used spanning to the width of the containing group, so the overlay change makes them cover the block's content.