Overhaul sibling inserter to only appear after a selected block

[ZebulanStanphill]

Issues with the current sibling inserter

The current sibling inserter is a lot better compared to some previous iterations, but there are still some major issues with it:

• It is attached before blocks, rather than after, which is confusing for keyboard users. To insert a block, I have to tab backwards from the block toolbar, which is very counter-intuitive. I would expect to be able to tab from the block content to an inserter.
• It covers up part of both the block above it and below it. This means that margins have to be added to all blocks to ensure the sibling inserter does not get in the way. These margins are there even when blocks are unselected. This runs counter to one of the big goals of Gutenberg: WYSIWYG editing, and is a pain to deal with in CSS. Ideally, the inserter should appear outside the currently-selected block content... just like the block toolbar which appears above the currently-selected block content.

My proposal to revise the sibling inserter

I propose that the sibling inserter be overhauled to work something like this:

• The current on-hover sibling inserter should never appear above or below the current block.
  • It already doesn't appear above it, and appearing below it would be redundant and confusing due to the other suggested changes.
• When a block is selected, an always-visible sibling inserter appears below the block's bottom edge. (Or in horizontal contexts, on the right edge, of course.)
  • This fits in with Gutenberg's philosophy of showing contextual controls when something is selected.
  • It ensures that the inserter is only covering up a small portion of the following block (no more need for the wide div used to detect hovering within a certain area). This makes clicking the block-after-the-selected-one nearly fool-proof compared to the somewhat hacky solution currently in place.
  • It ensures that the inserter is never covering any part of the block you are currently editing.
  • It solves the tab order issue, since the inserter now appears below (in horizontal contexts: to-the-right-of) the selected block, which is the most likely spot where you will want to insert a block.
  • It greatly improves discoverability, since it is constantly visible below the selected block.
• The block appender that automatically appears at the end of posts and InnerBlocks areas should be removed, since you could just select the last block and use the inserter that appears after it.
  • This improves the WYSIWYG-ness of the editor. The current after-last-block appender takes up space, pushing stuff around on the page as your focus moves in and out of various nested block contexts. By removing it in favor of the style of inserter I'm suggesting, there would be far less jumpiness.
  • By getting rid of the appender that appears only in specific situations (and confusingly not after Paragraph blocks), the UI would be simplified and made a lot less confusing.

Additionally, the following could also be done, but is not strictly necessary for this proposal:

• The on-hover sibling inserter could be removed entirely.
  • This keeps the UI clean by reducing the constant flash of appearing/disappearing controls as your mouse moves around the editor.
  • This would make selecting small and cramped blocks a lot easier since there would be no sibling inserters covering over them.
  • This would also reduce the number of inserter-types in the editor again, further simplifying the UI.
  • The downside is that this would make inserting a block take a little bit longer for mouse users. But then again, it's only one extra click.

Mockups

Here is a mockup of what the after-selected-block sibling inserter could look like. I figure that if it is always visible, it would make sense to align it to the left to fit with the block toolbar. Inserters in horizontal contexts (e.g. Navigation, Buttons, etc.) could remain in the middle if desired.

When hovered, it could show the insertion point as a line, to make it a bit more clear where the block is being inserted (helpful for situations with columns).

Related issues and PRs

• In-Page Inserter Revisions #10519
• reposition of in-between inserter and make it optional #11798
• Clicking top area of Paragraph block allows multiple "+" to exist #12264

[afercia]

When I tab to a block, I would expect that the next inserter I encounter would come after the block I just focused, not before.

I'd +1million this. Thanks @ZebulanStanphill

[ZebulanStanphill]

Updated the mockups to reflect the changes made to the Gutenberg UI since I made this issue.

[enriquesanchez]

Hey @ZebulanStanphill!

I believe this issue can be closed now given all the recent improvements and updates to the sibling inserter (#18941, #19456, #19596 and #11969).

[afercia]

I saw #10471 and #11345 were closed as well and that makes sense as the recent changes to the sibling inserter solve those issues.

However, this specific issue first point asks to move the inserter after a block. Instead, the new implementation keeps the inserter before the block thus this issue main point is not addressed yet.

[chrisvanpatten]

We've found it's confusing to our editors why they don't see the in-between/sibling inserter button below the current block if the last block is a paragraph.

I think using enter to insert the next block is intuitive if you intend to insert another paragraph — it's a lot less obvious that you'd need to hit enter for a new paragraph if you actually intend to insert some other type of block which is not text based (e.g. an image, or columns, or some other type of block).

This has long bugged me and I'm hoping now with some of the improvements around lightening the block DOM and moving some of these controls to be popovers that this might be easier to implement.

[ZebulanStanphill]

@chrisvanpatten It's also worth noting that in some blocks, e.g. the Preformatted block, Enter can't be used to insert a new block, because it just inserts newlines in the current block. So the only consistent keyboard method to insert a new block is to reverse tab to the sibling inserter. (Which, as stated before, inserts above the current block, which is almost certainly not what most people want to do.)

[ZebulanStanphill]

Something that I've noticed recently with the most recent UI changes is that, due to the slower fade-in for the sibling inserter, some people think it has been removed in Gutenberg 7.7.0.

But before that, I recall several people complaining about the flashing UI that would happen as you moved your mouse around and the sibling inserted popped in and out.

In my proposal, the sibling inserter is shown constantly below the block, and only under the selected block. This solves both of the above issues.

However, it comes with the downside of no longer being able to hover over an area to reveal the sibling inserter and immediately insert a block; instead, you have to first select the block before the spot where you want to insert. Then again, it's worth noting that the hover-revealed sibling inserter is only useful to mouse users; touchscreen and keyboard users can't take advantage of it. Meanwhile, a constantly visible sibling inserter below the block would be better for both keyboard and touchscreen users.

[paaljoachim]

An associated issue.
Here is an issue in regards parent/child in using the Buttons Block.
#21509 (comment)

[richtabor]

This is related to the suggestion I made on #22867, although I'm thinking only displaying while hovering, or keyboard focused on blocks. Kinda keeps the "editing a block" vs. "adding a block" action more separate/clearer.

[richtabor]

Let's see if we can get an experimental PR together to try this. Any takers?

[kirilzh]

Hi, I would like to work on this :)

[ZebulanStanphill]

@kirilzh Feel free to create a PR! That's the best way to find out if this will work and how it compares to other approaches. 😄

[richtabor]

This is really similar to #22867, but different. #22867 is about revealing the before and after inserter on block hover/focus - whereas this issue is about revealing the after inserter on focus only.

I think it'd be a good to have a PR for both to experiment with as its a pretty critical improvement.

[mapk]

Looks like we're moving to a PR with this for testing. I've changed some labels around for that purpose.

[youknowriad]

I think this PR #28418 mostly addresses this. At the moment the in-between "hover" inserter doesn't necessarily appear before or after a block but it shown at a given position. In #28418 we allow after the last block in a container as well. That said, sometimes it's hard to trigger because there's no difference between "after the last block in a container" and "after the container" unless there's a padding in the container (some space after the last block but before the end of the container).

[ZebulanStanphill]

@youknowriad Of the three points that were listed in the original post, I think only the visibility issue could be considered addressed with the current design. I've updated the issue description and mockups to better reflect the current state of the editor and the benefits that would still be provided by my proposal even now. If there is any unclear wording, let me know.

[youknowriad]

Ideally, the inserter should appear outside the block content just like the block toolbar.

This is not possible since it means it will overflow on top of another block and get in the way of selecting that block.

[ZebulanStanphill]

Ideally, the inserter should appear outside the block content just like the block toolbar.

This is not possible since it means it will overflow on top of another block and get in the way of selecting that block.

I should have clarified (and will now update the description) to say:

Ideally, the inserter should appear outside the currently-selected block content just like the block toolbar.

And besides, the current inserter already overlaps the next block in addition to the previous one. My change would reduce that to overlapping just one (plus no more wide hover-area rectangle hitbox with hacky click redirection... just the actual button size and maybe the thin line shown when that button is hovered).

[youknowriad]

How would you trigger the in-between inserter that shows up between blocks anywhere in the canvas (not necessarily selected ones)? How do you address this interaction?

[ZebulanStanphill]

How would you trigger the in-between inserter that shows up between blocks anywhere in the canvas (not necessarily selected ones)? How do you address this interaction?

As pointed out in the current issue description, I think that it could either be left mostly unchanged (only changed to not appear after the selected block so as to not interfere with the appender there), or else we could just remove it entirely. I think an inserter appearing after the selected block might be simple/predictable/intuitive enough to eliminate the need for the on-hover inserter. Of course, a PR to actually test this hypothesis would be good.

Also, I just updated the issue description again to clarify a bit that in horizontal contexts (Navigation, Buttons, etc.), the inserter would appear to the right of the current block, rather than below, for obvious reasons.

[youknowriad]

There has been a lot of iteration on the inserters since this PR was last updated. I think we're in a very different situation today when it comes to keyboard interactions and in-between inserter. There are still some merits to the ideas outlined in the issue but at this point, it's better to create a new clearer issue if needed.