Skip to content

Spacer markup could be more flexible #33018

Open

Description

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions