I have spent too many hours refactoring custom block attributes so a client could change a width or a height. Anyone who has been in the Gutenberg trenches knows the pattern: hand-rolled inspector controls, UI that looks slightly different in every block, and CSS held together with duct tape. WordPress 7.0 dimensions support replaces that bespoke code with standardized controls.
Until now, a block that needed width or height controls got them as custom attributes with a hand-built editor UI. Every block ended up feeling a little different, and there was no clean route from those values into theme.json, so global styles stayed a mess for anything to do with layout dimensions. In 7.0, width and height are part of the block supports system like everything else.
Native width and height block support
Opting in no longer means building a custom InspectorControls component in React. You toggle the supports in block.json and stop there. If you have already moved to PHP-only block registration, this is even less work.
{
"supports": {
"dimensions": {
"width": true,
"height": true
}
}
}Once you have opted in, WordPress renders the Dimensions panel itself and serializes the CSS for you. Default values go in theme.json, which gives you a cleaner cascade across the site and cuts the duplicate CSS you were shipping to the browser.
Dimension size presets
The dimensionSizes setting is the part I actually care about. Instead of letting someone type an arbitrary pixel value and break the layout, you hand them a curated set of presets. It works the way typography and spacing presets already do, so the design holds together.
You define these presets in your theme.json settings:
{
"settings": {
"dimensions": {
"dimensionSizes": [
{
"name": "Standard",
"slug": "standard",
"size": "480px"
},
{
"name": "Wide",
"slug": "wide",
"size": "720px"
}
]
}
}
}WordPress generates CSS custom properties on the --wp--preset--dimension-size--{slug} convention. Under 8 presets, the editor shows a slider. Past that it switches to a dropdown, which keeps the sidebar from looking like a cockpit. It is a small detail, and it is the kind of thing that decides whether the panel is usable in modern WordPress environments.
Where each setting lives
| Feature | block.json key | theme.json key |
|---|---|---|
| Width Support | supports.dimensions.width | settings.dimensions.width |
| Height Support | supports.dimensions.height | settings.dimensions.height |
| Dimension Presets | — | settings.dimensions.dimensionSizes |
If this kind of block refactor is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
Moving your blocks over
Switching to native supports keeps your blocks working with Global Styles and the Site Editor, and that is the part that pays off a year from now. The official PR #71905 and the updated theme.json reference cover the details I skipped here.
