Dimension Tools and Controls

[youknowriad]

This is a sub part of #27331

The tools to configure the spacing of a block are among some of the most incoherent tools we offer, with controls usually scattered across different panels and standalone tools. (See #23770, #24874, #26368, #22956, #14747.)

The proposed dimensions panel emerges as the consolidation of controls relating to the space a block occupies on the page. This includes but is not exhausted by height, padding, width, possibly alignment, and so on. Much like the typography panel, these controls are not always going to be present for every block, so it’s important individual controls can be toggled on and off as required, and that blocks can expose those that are considered default options based on configuration. The focus in this exercise is to test how the different controls ought to be laid out.

Let's try to split the work needed to achieve the proposed output in these mockups:

Height Control

• Build a block support flag (client and server) to enable "height" controls for blocks. The flag should automatically add a "height" attribute to the block, add the UI to the "Dimensions" panel, and apply the style automatically to the wrapper.
• Global styles support.
• Enable the height control flag in some experimental blocks (FSE blocks)
• Migrate the adhoc "height" attributes and UI we might have in exiting blocks.
• Decide whether it should be opt-in (with potential smart defaults depending on the container) or opt-out for block authors and enable the flag for all the desired blocks.

Question Should the height attribute be its own block attribute or should it be part of the "style" attribute.

Width Control

I'm not talking here about the "full width"/"wide width" UI here but more about the "width" control we have right now in some blocks like "column" or "button". Basically the equivalent of the height control shown as an input.

• Build a block support flag (client and server) to enable "width" controls for blocks. The flag should automatically add a "width" attribute to the block, add the UI to the "Dimensions" panel, and apply the style automatically to the wrapper.
• Global styles support.
• Enable the control flag in some experimental blocks (FSE blocks)
• Migrate the adhoc "width" attributes we might have in exiting blocks.
• Decide whether it should be opt-in (with potential smart defaults depending on the container) or opt-out for block authors and enable the flag for all the desired blocks.

Question Should the attribute be its own block attribute or should it be part of the "style" attribute.

Padding

We do have an existing support flag for padding, so we need to adapt it to work consistently to the other controls.

• Make sure the padding flag works in both client and server Global Styles: Add padding server-side block support #30332
• Enable the control flag in experimental blocks (FSE blocks)
• Decide whether it should be opt-in (with potential smart defaults depending on the container) or opt-out for block authors and enable the flag for all the desired blocks.

Margin

The primary focus for this is to provide a spacing option between the blocks that can work globally.

• Build a block support flag (client and server) to enable "margin" controls for blocks. The flag should automatically add a "margin" attribute to the block, add the UI to the "Dimensions" panel, and apply the style automatically to the wrapper. Spacing Support: Add margin block support with configurable sides #30608
• Global styles support.
• Enable the margin control flag in some experimental blocks (FSE blocks)
• Decide whether it should be opt-in (with potential smart defaults depending on the container) or opt-out for block authors and enable the flag for all the desired blocks.

Block Alignments

What we call block alignments is the "full width"/"wide width" UI shown in the mockups and sometimes it can include "left/right"... We do have a support flag for these called "align" but it has a few issues: It's not used consistently in blocks, some blocks have their own custom "align" support. Another problem is that it uses the "align" attribute which might have a different meaning in some other blocks.

The other issue here is that this control only make sense in the "default" layout (Meaning if the container is just a normal vertical list of blocks). In different layouts like the "flex" layout (which already exists in the code base but in an implicit way using the "orientation" prop), these alignments don't make any sense.

I think here we need to be more generic and instead of talking about "block alignments" we should just talk about "position". So inside a "default" layout container, the values can be "wide"/"full"/"left"/"right"/"center"/"none" but inside a "flex horizontal" container, these values don't apply and inside an "absolute container", we might have "x and y", inside a "grid" container we might have something else (rows, columns)

So I think what's important here at the moment is to scale down the scope to the "default" layout but we keep in mind how this attribute should or shouldn't translate to other future layouts.

Based on this, here's what I think should be the plan here:

• Build a block support flag (client and server) to enable "position" controls for blocks. The flag should automatically add a "position" attribute to the block, add the UI to the "Dimensions" panel, and apply the classname automatically to the wrapper. The UI should only show up if we're inside a "default" layout container otherwise it doesn't.
• Make sure that the"position" doesn't persist when moving blocks to a container with a different layout type
• Global styles support.
• Automatically set the layout to "flex-horizontal" for blocks that pass orientation="horizontal" to their InnerBlocks.
• Enable the control flag in experimental blocks (FSE blocks)
• Decide whether it should be opt-in or opt-out for block authors and enable the flag for all the desired blocks.

[youknowriad]

Started working on some of these. First thing is adding padding block support to dynamic blocks.

[youknowriad]

Started working on the margin block support in #30371

[youknowriad]

Padding server-side support flag is now merged.

[aristath]

Have we considered using a box-model control like the one browsers have in their dev tools?

Using something like that we could have padding, margin, borders, all in one, using a familiar UI, and we can definitely toggle features on/off by making some of the values editable...
A couple of years ago I built something similar for the customizer and it was pretty convenient at the time

Visually it was meh, but that's easy to fix... functionally it was intuitive and accessible

[jasmussen]

I ran into needing a margin today. This will be such an important tool to build great patterns.

[priethor]

As @jasmussen says, margin support seems to be one recurring tool required by many theme blocks to build rich patterns.

[carolinan]

I saw that a PR for adding support for margins to the site title block was merged.
If this is now implemented, shouldn't margin controls be enabled by default for all blocks?

[jasmussen]

If this is now implemented, shouldn't margin controls be enabled by default for all blocks?

I'm conflicted here. On the one hand, I deeply want this feature for better patterns. On the other hand, the current margin controls are very clunky, and there isn't a #27331 inspired design for how we surface margin/spacing in a user-friendly way yet. For example while we might know by heart the difference between margin and padding, this is not necessarily obvious for the average user — so do we put margin and padding behind a segmented control? Do we take up space and have controls for both visible at the same time? Is there an alternative that better abstracts the controls? It's a difficult design, and every feature we surface adds weight, even if it's a collapsed-by-default panel.

Question: can we enable margin support for all blocks through theme.json and markup, without surfacing the UI for it yet? While not the most obvious interface for building patterns, at least it would be technically unblocked as we refine the UI for it.

[aaronrobertshaw]

Margin block support was added in #30608.

I'm also starting to work on updating the spacing support panel into the proposed "Dimensions" panel. Once I have that in place, the plan is I'll add height and width support to that.

[aaronrobertshaw]

There is a proof of concept up for the Dimensions panel in #32392.

It focuses on adding a new component that can easily be reused across multiple block supports. The individual block support controls for margin and padding can be updated as the G2 component matching the design gets imported in the near future.

The linked PR uses the new component to convert the current Spacing support panel into the basis for the new Dimensions panel. I'll be adding height and width support to it soon.

[MaggieCabrera]

Just chiming in to say that although margin controls usually work fine on most blocks I've encountered some that give you errors such as:

<!-- wp:separator {"className":"is-style-wide","style":{"spacing":{"margin":{"bottom":"20px"}}}} -->
<hr class="wp-block-separator is-style-wide" style="margin-bottom:20px"/>
<!-- /wp:separator -->

While showing up correctly in the frontend.

[kjellr]

It is then from those attributes that the block is dynamically rendered on the frontend. Without opting into the appropriate support via the block.json the block doesn't know how or if it should translate those style. attributes into inline styles.

Hopefully, that helps paint a better picture than my last comment 🙂

Yes, definitely — that's helpful. It seems like the issue described in #35522 is due to this specifically being a dynamic block then. We can fix this by enabling margin controls for that block (#35684), but is this something we could fix behind the scenes for all dynamic blocks?

It might be that we only wish to enable top and bottom margins in most cases.

Can we try doing this in a PR and see how it feels?

[aaronrobertshaw]

We can fix this by enabling margin controls for that block (#35684),

Just for clarity, at the minimum, we'd only need to opt into the block supports not enable the controls in the UI. Which is what #35684 does.

but is this something we could fix behind the scenes for all dynamic blocks?

It would be a matter of opting into margin support for each of those dynamic blocks. There are some issues still around how a block's margins play with overrides enforced on top-level blocks by the layout support or the new block gap support in some circumstances.

Until those issues are discussed and a decision has been made on what needs doing, I don't think we can just blindly opt-in all dynamic blocks.

An example of the issues around adding margin support can be found in #33835. These are concerns for both static and dynamic blocks.

Can we try doing this in a PR and see how it feels?

It would certainly add to the discussion. It might be easier to do this on a block by block basis though as the need arises, given the inevitable wrinkles we'll encounter.

[carolinan]

I have no problem creating the small block support PR's for individual blocks, but I'd like there to be a decision about it and for 5.9 and TT2 there is not much time.

[apeatling]

Added this to the design tools project overview, apologies for all the assignments above. https://github.com/orgs/WordPress/projects/10/views/1

[ndiego]

Hi all, looking to continue this discussion. Now that things are much more solidified as we get closer to 5.9, I believe it makes sense to explore adding additional dimension controls (the editor UI) to more block types for post-5.9 releases. I have begun by creating a PR for paragraph blocks #37300 and here is the related issue #37299.

I will also be working on PR for the Group block to include both margin and blockGap later this week. Given that theme developers can easily opt-in/out of this functionality in theme.json, I believe this is only enhances the capabilities of the block Editor with very little, if any, downside. It also greatly reduces the need for custom CSS and/or "magic classes" to attain certain theme designs.

[mtias]

Thanks for looking into this followup @ndiego. Out of all the dimension tools, margin is the trickiest to expand, particularly to non-layout blocks, because it's not easy to grasp how it works or how it interacts with adjacent margins. It also makes it difficult to reason about when it comes to boundaries — like deciding where to add a margin within or outside template parts.

Towards 6.0 I'd like us to explore using the Spacer block as a replacement for most margin needs. I know this sounds backwards, but the spacer block is a lot more intuitive for end users to reason about, they can move it separate from the rest of the blocks, they can manipulate it directly, etc. On flex layouts, the spacer can better reflect organization and adapts to vertical or horizontal displays. There's also nothing preventing us from transforming a spacer block into adjacent margins server-side if we want to avoid rendering an empty element in the DOM.

If we do this correctly, I can see a world where margin is left as an advanced tool for creators, more hidden by default.

[ndiego]

Thanks for the thoughtful response @mtias! I completely agree that the spacer block is much more intuitive and is great when users need to add spacing between blocks. The use-case that the spacer block does not solve is removing margin, particularly in blockGap scenarios where margin-top: X is added to every block. Similarly, for paragraphs in particular, most themes and even browser defaults add margin to <p> tags. When designing a layout in the Editor there are many instances where you would want to zero out or modify this margin. I guess if there was even a way to remove all margin and then any spacing could be added with spacer blocks, that would be a happy compromise. I just strongly feel that having to include "magic classes" in a theme to counter applied margin is more of a barrier to users and antithetical to the goal of the Block Editor.

Note that I am operating from the standpoint of wanting to be able to design entirely in the Editor. If a theme's style.css file could be completely empty of custom CSS, that would be my dream state. Regardless of the correct solution to this dimensions issue, and I know that blockGap is being rethought a bit here #37360, I believe it's important to make these controls accessible in the Editor, even if hidden behind a toggle, user preference setting or configurable in theme.json. While we absolutely do not want to overwhelm/confuse newer users, we also want to enable advanced users to harness the full power of the Block Editor. I know this is a hard balance and a difficult problem to solve. I am happy to help in any way that I can!

[jasmussen]

I created #38068 which contains mockups for improving the Image block inspector, notably adopting the general Dimensions panel.