Visibility conditions for the drag handle in child blocks

[oandregal]

Since the drag handle has been moved to the block mover in #9569, it obeys the same visibility conditions than the block mover: it's only shown when there is more than 1 block in that context.

Take for example the columns block:

If the column has more than 1 block (like the one in the left) the block mover is shown. If it only has one (like the one in the right), it is not.

Should we make the drag handle visible always for child blocks, so they can be moved outside the parent block at any time?

[oandregal]

cc @karmatosed @jasmussen @mtias

[jasmussen]

Should we make the drag handle visible always for child blocks, so they can be moved outside the parent block at any time?

I think that could make sense.

However it begs a different question: why are the movers disabled in the columns block when there's only one block? I can imagine the obvious answer, because it's at the top of the columns block. But is this desirable?

Say you had this:

[Paragraph]

[Columns]
  [Paragraph] [Paragraph]
[/Columns]

Right now if you press the down arrow on the first Paragraph, you get this:

[Columns]
  [Paragraph] [Paragraph]
[/Columns]

[Paragraph]

But should you get this?

[Columns]
  [Paragraph] [Paragraph]
  [Paragraph]
[/Columns]

I realize that sounds weird on the face of it, but why? Try using the arrow keys in the above setup. Press down arrow from the first paragraph, you then select the columns block. Down again selects the first column (singular), down again selects the first paragraph in the first column, down again selects the 2nd column, down again selects the paragraph in the 2nd column block, etc. etc.

Should the movers behave the same?

It would obviously be a problem with nesting containers that don't support a particular block, but this is the same challenge with dragondrop, and presumably the solution could be the same?

[chrisvanpatten]

Just one guy's opinion but I think the movers should always be visible, unless a template lock is active. Otherwise, show them all the time.

@jasmussen That's an interesting idea. It does start to fuzz the edges around where blocks start and end and how content moves through them, which concerns me a touch. Right now it's fairly clear that the movers work within a single block level, but not between levels. Drag and drop is sort of a separate experience even though it's related to the movers — there's more of an intuitive expectation with drag and drop that you can position a block at any place on a document.

Now that said there's also an a11y factor here, because as it stands right now users who interact with Gutenberg exclusively via the keyboard don't have a way to move content into nested blocks. That fix could solve that problem.

All in all and interesting idea though, and certainly worth getting more feedback on!

[jasmussen]

I think it's a solid argument, and perhaps I should clarify that my discussion point is perhaps best something to think about, rather than have it block this legitimate improvement.

I see nothing wrong with us making the drag handle visible always for child blocks as a starting point, and then I'm sure this will surface again if it becomes an important problem solving aspect.

[chrisvanpatten]

(Also potentially relates to #10093.)

[karmatosed]

As we seem to have design feedback for this, let's focus on the solution here. Thanks everyone.

[ZebulanStanphill]

The drag handle is now always visible for child blocks; in fact, the entire mover is always visible (though the up/down buttons are disabled when there is only one block). I'm closing this issue as the problem is fixed.