Drag & Drop: Change to use hover label as the draggable handle

[jasmussen]

Right now drag and drop happens by grabbing any one of the four sides of the block and moving.

Given recent changes to how you hover and select blocks, notably parent blocks, this is not ideal, as it covers a fair amount of space left and right that is invisible, and could be used to select the parent block instead.

We should consider using the new in 3.0 hoverlabel that sits in the top right corner as the only place where the block can be dragged. It could look like this:

It could have an indicator:

[karmatosed]

Apologies for slipping and assigning this.

I really like this idea and that indication I've seen used before.

[ZebulanStanphill]

I think this would definitely be an improvement over the current UI. (I previously suggested pretty much this exact same thing a while ago, but for the old hover title in #6265.) Having drag-and-drop be usable through invisible paddings/margins always felt weird and confusing to me.

[StaggerLeee]

You really need to fix this several pixels thick line when using drag & drop. I am following Gutenberg from early days and I barely noticed it. It is not nice as it is now, very hidden.

Second problem is you expect people to drag & drop blocks with horizontal tolerance in pixels almost perfectly. Again, real life does not work this way. People take it with mouse, or notebook touchpad, and move it several pixels left-right from your imagined limits. Then drag & drop thick line is gone.

You have DIV "editor-block-list__block" (with unique ID for each), and give people some freedom not to be perfect. Treat drag & drop movements against this DIV, not against "components-draggable editor-block-list__block-draggable"

But this problem is less serious than first one with almost invisible thick line.

I suggest you to ditch this D&D line and instead use subtle background-color change of whole "editor-block-list__block" DIV.
But, it can work only if React can do something like this: https://bevacqua.github.io/dragula/

Edit: I see now tolerance when dragging a block is absolute at the right of block container. Just make it similar at the left. Is User drag block just 5 pixels left of the block DIV inserter line is gone.

[designsimply]

Right now drag and drop happens by grabbing any one of the four sides of the block and moving.

Note: I tested this today with 3.2 and found that I can only grab the left and right sides of a block for drag and drop (probably because top and bottom were taken over by the block inserter) and that makes it so I cannot get a hold of draggable handles for wide blocks using full-width— see #7914.

[ZebulanStanphill]

See also #6224, which may make this change unnecessary, depending on how it is implemented. I think that in both cases, the drag areas near the borders should be removed, since they have always been rather confusing.

[ZebulanStanphill]

Depending on how #6224 is implemented, this may still be necessary. Due to issues with overlapping toolbars from the currently selected and the currently hovered block, it may end up being decided that the hovered block should not show the block controls on hover like it does now. In that case, allowing the hover label to be used as a drag handle would make sense, since there would be no other good place to drag it from. (The current invisible drag areas on the sides are confusing.)

[oandregal]

I can take this.

With the current implementation, we can Drag-n-Drop a block even when it has the block toolbar activated. The block hover label isn't shown at that point so we won't have DnD on the block the user is working with if we use it as the handle. Would this be OK? Or perhaps we would want to expose the handle when the user hovers to the right side of the block, as we do with the block settings menu?

[ZebulanStanphill]

@nosolosw The outcome of this issue is partially tied to #6224. Depending on how that issue is resolved, there may end up being a large bar below the block with plenty of drag space.

Additionally, I have often suggested making the toolbars (including the parts with buttons) double as drag handles, similar to the title bars in GNOME.

I would prefer not to have the hover label appear on hover on the selected block, given the above other possibilities for drag handles.

Also, as I have stated in a previous comment, having the hover label act as a drag handle may be unnecessary if the same wide bar shown for selected blocks is also shown on hover. However, as discussed in #6224, having all this UI shown for hover blocks may result in more overlapping UI issues than exist now. This would be resolved by having all the controls on either the top or bottom. However, having all controls on the top looks weird when adapting to thinner blocks and is not ideal for accessibility, and having them all on the bottom raises issues with the formatting toolbar possibly overlapping the text you are editing, and both result in UI getting pushed around when you select a block that you are currently hovering.

An alternative solution that allows the formatting toolbar to continue to be shown on top while the arrow movers and ellipsis (and drag handle) to be shown at the bottom would be to simply not show any toolbars on hover. However, having the arrow movers and ellipsis menu appear on hover is really useful.

On top of all that, there is the issue of the sibling inserter and how it fits in to all of this. If a bar with the arrow movers and ellipsis is shown below a block, then the sibling inserter could be thrown in there as well, fixing all issues of the sibling inserter overlapping the content of the current block while also making it always visible for the current block and putting it below the current block (which makes more sense than having it always technically be attached to the top of blocks, but not the currently-selected one). See also: #7271 and #7763.

So as you can see, all these things are rather intertwined. Changing one ends up affecting all the others.

[jasmussen]

Good thoughts, not let's not let #6224 block this from happening. Even if 6224 happens, the refactoring to use a single element instead of all the borders for dragging is going to be helpful and make even 6224 easier to implement.

[oandregal]

Closed by #9569

[chrisvanpatten]

RIP hover label drag handle… we hardly knew ye.