Do not show block movement controls unless cursor first moves into corresponding block.

[ZebulanStanphill]

The issue

Don't you just hate it when this happens?

And what about this? (This case is now gone thanks to #9074.)

I don't know about you, but having the block tools of another block appear when I have not even hovered over that block can be quite annoying, particularly when it overlaps the block I have selected.

To make the side controls easier to reach, there is an area below them where moving your mouse there will make them appear. However, this often gets in the way, especially in nested contexts.

Proposed solution

I think the movement controls and ellipsis should never become visible if your cursor does not first move into within the borders of the block they are attached to. This would reduce the likelihood of the controls suddenly appearing and overlapping the selected block when you don't want them to.

Other notes

This is an attempt to make the current block side controls less confusing and improve the user experience. Since no solution to #6224 has been agreed upon yet, it would be best to improve the current UI as much as possible in case the controls-on-top/bottom idea does not work, and also considering the oncoming merge proposal and WordPress 5.0 deadlines.

Related issues and PRs

• Display block tools underneath the block, instead of to the sides #6224
• Add a delay to the blue outline + block type label on hover #8836
• Move the blocks "More" button (ellipsis) to the toolbar #9074
• Revise sibling inserter to be more consistent, appear in a more logical position, and not overlap the content of the selected block #9202

[designsimply]

To make sure I understand, this is what I am hearing: you would like the hover areas below block more menus and mover tools for blocks adjacent to selected nested blocks to be smaller so that they are not triggered when hovering over another block unless you are directly hovering over the block more menu and mover tools themselves. If this interpretation is correct, then the proposal is to remove the following areas as hover-able:

Video: 59s
^{Seen at http://alittletestblog.com/wp-admin/post.php?post=13886&action=edit running WordPress 4.9.8 and Gutenberg 3.5.0 using Firefox 61.0.2 on macOS 10.13.6. Note that the areas outlined may vary slightly for different browsers.}

Notes: I see a possibly negative tradeoff for discoverability and accessibility when making target areas smaller. I generally argue for larger target areas for this reason. I am not sure how much this matters since the areas being discussed in this case are fairly small already. Something more important to consider is that this may not be an easy thing to do with code and also make it cross-browser compatible and accessible, so it is worth considering that the potential benefit gained by this proposal may not be worth the extra code needed to make such a precise change. I am not sure how much code would be needed and am noting that it is something to consider in this case.

[ZebulanStanphill]

@designsimply I am asking for the entire trigger areas on both sides to be removed: not just the area below the controls, but the area where the controls themselves are. The controls would appear only when hovering over their block and when hovering over them when they are visible. However, hovering over the place where they would be without first having hovered their block would not cause them to appear. In other words, if the controls are currently invisible, hovering over where they would appear should not make them appear.

Essentially, they would act a bit like the tooltips in Gutenberg. Tooltips don't appear when you hover over where they would be unless you first hovered over their corresponding control. I would presume that the CSS to accomplish this would be fairly simple, but I don't know for sure.

Of course, I do not consider this a perfect solution. However, this is the only way I know of for the current UI that ensures that you can always reach every part of the selected block, which I consider to be really important. Nothing should ever constantly prevent you from clicking a spot in the content of a block. Right now, there are cases where hovering over a spot in the selected block will always cause the controls of the adjacent block to appear, overlapping the spot you are trying to reach; this means that there may be no easy way to reach that area of the block. This should never happen.

I consider fixing this to be worth the slight decrease in discoverability. Right now, there might be more discoverability, but it is impossible to reach some areas of a block without having to go out of your way to use tabbing or the arrow keys. With this change, the side controls may be slightly harder to discover, but they are still very much discoverable, and their appearance should align more closely with when you are actually trying to use them, rather than when you are trying to edit another block.

[chrisvanpatten]

@ZebulanStanphill Does this still apply with the recent changes to the movers? (Genuinely don't know; I don't have a copy of master running at the moment)

I suspect it still happens, but worth checking…

[ZebulanStanphill]

@chrisvanpatten Surprisingly, it is a lot better now. The behavior is still the same for unnested blocks, but for nested blocks, the controls only appear once you have hovered within the borders of the block. Once you do this, there is an area below the movers that you can move your cursor into, but the controls will still be visible, and the invisible area will prevent you from clicking any block covered by it. I think this behavior is confusing (you think you can click on a block, but it is covered by an invisible hover area), so I think the invisible hover area below the movers should be removed.

[ZebulanStanphill]

Should I rename this issue to reflect the remaining issue, or should I open a new one instead?

[designsimply]

I re-tested this again just now using WordPress 5.0.3 (no active plugins) with Firefox 65.0 on macOS 10.13.6 and it's looking even better. I think we can close. Please open a new issue if you feel strongly it needs to be re-visited. Thank you!

[ZebulanStanphill]

I think a solution to #9628 and improvements brought by the resolutions to related issues like #10519 should solve most of the issues with the current UI (perhaps even including the changes I'm proposing here), so I'm fine with this issue remaining closed.