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 #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. #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.