Spacer markup could be more flexible

[tellthemachines]

What problem does this address?

Currently, the Spacer block outputs a styled div with aria-hidden=true. This works well for most purposes, except if we need to insert it somewhere where a div is not allowed, e.g. inside a list. We came across this problem in trying to add Spacer in Navigation block submenus.

What is your proposed solution?

There are two possibilities here:

1. We modify the Spacer block so that it renders different markup when inside a list. Its default would still be div; perhaps we could leverage context to have its parent tell it to output an li when inside a Nav block. This has the advantage of being easy to implement and no real disadvantages apart from outputting essentially useless markup, which the Spacer block already does anyway.

2. We make it possible for block save functions to output attributes that can be attached to the previous or next block, as opposed to outputting actual markup. The Spacer save function could then output a style tag with a margin-top or a margin-bottom that could be attached to an adjacent block. (Or... the technical implementation doesn't matter yet as much as thinking through the consequences of not rendering markup in this block, and attaching styles to another block.) There are a few difficulties with this solution:

   • It requires there to be other blocks in the vicinity of the Spacer, so adding only a single Spacer to a page won't work.
   • It requires fiddly logic to check for if previous/next block exists, and change the style accordingly: say by default it outputs a margin-bottom on the previous block, but if there's no previous block, it has to output margin-top on the next block. Or in its horizontal iteration, this would be either a margin-left or a margin-right.
   • Because it only exists as an inline style, Spacer block behaviour can be broken altogether by overly specific theme styles, e.g. [class^="wp-block"] { margin: 0 !important }
   • Adding custom unit support, which is important to ensure responsive behaviour, will be complicated by the fact that em units refer to the element font size, so attaching a margin defined in em to an unknown block can have unpredictable results.
   • We won't be able to add a background color, and we'll be closing the door to website owners being able to creatively style their spacers.

Though it would be neat to not have to output any extra markup for this block, having thought this through a bit I'm inclining towards option 1 as the more solid solution.

Ideas/opinions/feedback welcome!

[jasmussen]

While the recent navigation markup discussions seemed to lean most heavily towards the top level menu items in a navigation, I would expect the bulk of the argument to remain the same for content inside submenus. That is, while the first phase of the navigation block is mostly about wrapping the features already in, the next phase would need to tackle mega-menus and highly customized overlay/🍔 menus, like these:

In that vein, it seems like we should be careful with limiting what blocks can be inserted and where. To that end, I imagine building out the contents of a submenu or burger menu should be no different from adding blocks inside a group or a columns block.

This is not to suggest any particular path forward for the Spacer block, but rather to clarify how submenus, in addition to top level menus, should be able to accommodate as wide a range of expression as you'd expect inside a Group block, and with the same basic interaction.

[tellthemachines]

That is a great point to bring up, as solving the mega-menu problem will likely make Spacer semantics a non-issue 😄
Why? With mega-menu dropdowns potentially containing multiple lists, images and other elements, the dropdown markup will have to be generic (a div wrapper instead of the current ul) which means we can treat the spacer like #30551 does for the top level Navigation block, i.e. rendering it outside of the list elements to preserve semantics.

I'll leave this open for now as we might want to come back to it, but let's work out how mega menus will look first.