-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spacer markup could be more flexible #33018
Comments
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. |
That is a great point to bring up, as solving the mega-menu problem will likely make Spacer semantics a non-issue 😄 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. |
What problem does this address?
Currently, the Spacer block outputs a styled
div
witharia-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:
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 anli
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.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:
margin-bottom
on the previous block, but if there's no previous block, it has to outputmargin-top
on the next block. Or in its horizontal iteration, this would be either amargin-left
or amargin-right
.[class^="wp-block"] { margin: 0 !important }
em
units refer to the element font size, so attaching a margin defined inem
to an unknown block can have unpredictable results.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!
The text was updated successfully, but these errors were encountered: