Sibling inserters should never constantly overlap the content of the selected block #8883
Labels
[Feature] Inserter
The main way to insert blocks using the + button in the editing interface
[Status] Duplicate
Used to indicate that a current issue matches an existing one and can be closed
[Type] Enhancement
A suggestion for improvement.
The issue
Sibling inserters take up a considerable amount of space in the UI. Not visually, but they actually do overlap a considerable amount of the content of a block. Currently, this does not cause many issues since all blocks currently have margins applied to their content, preventing most cases of overlap.
However, these automatic margins go against the idea of WYSIWYG editing and should probably be removed in the future (see #8350). Additionally, custom blocks and themes can already override styles, causing the overlapped area to become more apparent.
Thoughts on possible solutions
First of all, if at all possible, the area you hover to make the sibling inserter become visible should not prevent you from editing content that would be otherwise overlapped by the hover area.
However, this still leaves the inserter button itself overlapping a portion of the content. You could reduce this issue by making the button a bit smaller (it could be the same size as the inserter in empty Paragraph blocks), but the button would still be overlapping a portion of the block, albeit a small one.
In my opinion, no UI should constantly cover up part of the content of the selected block, making it unreachable. I think that the best solution here would be to make the sibling inserter button appear entirely outside the border of the selected block, just like the formatting toolbar, movement controls, and ellipsis.
Of course, a question is raised: what should the sibling inserter should look like with these modifications? I am not completely sure what the answer is. #6224 has some mockups integrating the sibling inserter into the same toolbar as the movement controls and ellipsis, and that would certainly fix this issue. However, no UI design in that ticket has been agreed upon yet, so perhaps the best solution looks different.
Related issues and PRs
The text was updated successfully, but these errors were encountered: