Navigation block: Add horizontal movers

[draganescu]

Some blocks have inner blocks that need to be moved horizontally, for example the menu block, the gallery block and the columns block. The block mover assumes that only vertical rearrangement is possible, so we need to implement a way to allow horizontal rearrangement.

[mtias]

This would be the addition of an orientation={ 'horizontal' } or just a boolean horizontal property of InnerBlocks. The movers would be just one aspect of it.

cc @felixarntz as this seems relevant to what you have been doing in AMP-stories territory.

[draganescu]

At this moment the BlockMover component is used in the BlockListBlock component and it is rendered in a shared container with the BlockEdit component. This is great for positioning the movers absolutely from the BlockEdit itself. It is not so great for having the BlockMover render inline next to BlockEdit.

Here are some solutions:

• duplicate the BlockMover code in BlockEdit and render it selectively based on some orientation flag, before BlockEdit for orientation:vertical and after BlockEdit for orientation:horizontal. This is OK, but the code in BlockMover becomes a bit messy.
• use display:grid on the shared container and place BlockMover on a column based on some orientation flag. This works, more or less, but it requires a redo of some of the current BlockMover CSS positioning code and raises accessibility issues as well.
• drop BlockMover into BlockEdit and have it render by default as vertical then leave each block do it's thing for mover variations. This way each block can decide to not render the default BlockMover and instead render something else. In the case of NavigationMenu render the mover inline with each NavigationMenuItem.

There are some other options though.

First, it bothers me that while vertical movers are standard horizontal movers vary: the gallery has horizontal arrows positioned absolutely on top of gallery items, the navigation block has horizontal movers positioned inline next to menu items. It feels off somehow. So, one option would be to not have horizontal BlockMover inline but absolutely positioned, like this:

or even simpler like this:

Second, maybe the whole movers thing could be improved for all the blocks if we implement something else in NavigationMenu such as:

• toolbar movers like @mtias suggested

• block movers implemented as one of @jasmussen 's explorations

• have a 'moving mode' of the toolbar as described by @karmatosed

So, are we sold with this idea that the NavigationMenuItem 's horizontal movers should be inline and look like the ones implemented by the Gallery block (which doesn't implement InnerBlocks but some custom way)?

Because if we are then, imho, the best way is to implement them custom in NavigationMenuItem just like Gallery does for its items and not as a general InnerBlocks feature.

[talldan]

• duplicate the BlockMover code in BlockEdit and render it selectively based on some orientation flag, before BlockEdit for orientation:vertical and after BlockEdit for orientation:horizontal. This is OK, but the code in BlockMover becomes a bit messy.

In order to get this option working for both the Nav Menu block and a Gallery that has inline blocks (and maintain tab order), I think there would need to be two additional BlockMovers rendered, one before the BlockEdit and one after. Configuration could be something like:

<InnerBlocks
  useInlineMovers="before|after"
  isHorizontalLayout
/>

The styling for these movers will be pretty complicated, which is why I think a BlockMover component that could be dropped into the block's edit will be easier to work with. I know the drawback with that is that it doesn't offer the out-of-the-box functionality that we want to provide block developers with.

[jasmussen]

In reading through this thread, it reads to me as if the biggest argument for duplicating the block mover code is that it makes it possible to apply some stylistic changes that are not possible currently, is that correct?

I love a challenge, so I would love to understand what style we want and what makes that possible with the current approach. I read this:

At this moment the BlockMover component is used in the BlockListBlock component and it is rendered in a shared container with the BlockEdit component. This is great for positioning the movers absolutely from the BlockEdit itself. It is not so great for having the BlockMover render inline next to BlockEdit.

What about the horizontal layout makes it hard to accomplish the horizontal movers based on what we have today?

If it helps, I can create an example PR where I unhide the movers from the recently merged Social Links block, and style those to be horizontal.

Note I do think in general that the block mover needs a lot of love. But those benefit deserve to benefit block movers everywhere, not just in nested blocks, IMO.

[draganescu]

After a lot of fiddling with the CSS ( cc @jasmussen ) in which I basically added a wrapper and used a CSS grid to move the movers around I gave up and found no way to make them stay in the same place in the DOM and look like this:

Therefore I went ahead and updated #16615 to have the BlockMover component be passed into any kind of BlockEdit. There each block which needs horizontal movers can render them wherever it sees fit:

The styling is crap because the MenuItem component is incomplete and has some outdated UI.

[talldan]

In reading through this thread, it reads to me as if the biggest argument for duplicating the block mover code is that it makes it possible to apply some stylistic changes that are not possible currently, is that correct?

@jasmussen I personally think tab order is the main issue. I'm sure there's lots that's achievable using purely CSS, but afaik CSS can't solve that the mover is after the content in the nav menu item, and before it everywhere else.

Happy to be proven wrong though 😄

[jasmussen]

Hey @talldan and @draganescu, thanks for blazing on with this, your work is very helpful in understanding the challenges involved, I know I've had a hard time understanding the intricacies. So these examples have been very helpful, to the point that I took a stab myself in #17627.

Basically it sounds like the primary motivator for making the block mover into a subcomponent, was to show it inline and to the right of the child item. For that reason I took a different approach, kept them where they are and just re-did them, kind of like Andrei did in one of the GIFs here: #16637 (comment)

I don't necessarily think this is the IDEAL solution, but it is a CSS-only solution that we can refine as we go, and it keeps with the idea of keeping the block, notably the innerblocks feature, as simple as we can for developers.

Would very much appreciate your thoughts.

[draganescu]

This issue is almost completed by #16615 which is missing a final review.

[ellatrix]

@draganescu Looks like the movers are not showing correctly in the top toolbar. See #19565.

[draganescu]

Hi @ellatrix I am afraid I'll need to get more up to date with moving the movers to the toolbar and what that means for how they work. I'll check the issue you opened and comment there.