Add width block supports under dimensions. #71905
Open
+213
−27
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ryanwelcher
added
[Type] Enhancement
|
Size Change: +147 B (+0.01%) Total Size: 2.54 MB
ℹ️ View Unchanged
|
ryanwelcher
requested review from
ellatrix,
spacedmonkey and
tellthemachines
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Mamaduka
reviewed
Sep 25, 2025
Comment on lines
85
to
90
| function useHasWidth( settings ) { | ||
| return settings?.dimensions?.width; | ||
| } | ||
| function useHasHeight( settings ) { | ||
| return settings?.dimensions?.height; | ||
| } |
Member
There was a problem hiding this comment.
Hey, @ryanwelcher 👋
Nitpick (non-blocking): Not sure when this naming pattern emerged, but these aren't actual React hooks, and we should avoid using the use prefix. Consider using hasWidth or a similar method name.
Contributor
Author
There was a problem hiding this comment.
Thanks for the fast review on this! There was a lot of existing code that I followed and I wanted to get it working and reviewed before I started making larger changes. I'll make those changes.
As a side not, it is NOT clear AT ALL how to add these supports. Might be work documenting this as I go.
Member
There was a problem hiding this comment.
Not a blocker, blocker at the moment. We'll probably have to rename this when we enable the React Compiler.
As a side not, it is NOT clear AT ALL how to add these supports. Might be work documenting this as I go.
Adding features to the core is rarely documented, but it's usually a matter of copying and modifying existing support. I think you're on the right path.
Contributor
Author
There was a problem hiding this comment.
I've renamed the function to something more appropriate in this PR #71905 71914
Contributor
|
Can we take a slower approach here and split this PR in two. one for height and one for width. Also, let's try to check which blocks already do have similar controls adhoc and update them if possible to use the block supports. |
|
Flaky tests detected in 3cfabac. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19100170111
|
Contributor
Author
Absolutely. I'll get two PRs in place. Do you want the block updates to be in the PR for each new support? |
Contributor
I don't mind being separate but it would help validate that things are working properly. (Maybe at least one block) |
ryanwelcher
requested review from
ajitbohra,
fabiankaegy and
juanmaguitar
as code owners
ryanwelcher
changed the title
4 tasks
Contributor
Author
|
I've split the |
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 6.9 Editor Tasks
Contributor
|
I'm not sure we should implement width and height controls without considering how they'll interact with layout and alignment supports. For instance, how will width work together with alignment on a block that has both? How will width work on child blocks of flex or grid layouts that already have width-adjacent controls such as fit/grow/fixed for flex and grid spans? Are these controls suitable for all block types? |
Contributor
|
P.S. It seems that @aaronrobertshaw did something similar about four years ago: #32502 |
Contributor
|
Alignments for me are "maxWidth" support basically. We could rename as such but I don't believe that we should try to be too smart and connect "maxWidth" and "width" support too much. I think we should be able to use both at the same time without them interacting much. (just embrace what CSS does) |
Contributor
Author
|
I just did a scan for blocks that have a
I'll take a look at converting some or all of these to use the new block supports. |
Contributor
Author
It @aaronrobertshaw wants to pick that up again, I'm happy to close this PR in favor of his. |
aaronrobertshaw
force-pushed
the
add/width-height-block-supports
branch
5 times, most recently
from
b51401a to
1c278b9
Compare
aaronrobertshaw
force-pushed
the
add/width-height-block-supports
branch
from
3cfabac to
bb1be96
Compare
Contributor
|
I've added a quick demo of the current width support in action showing global styles and block support styles working together. The use of presets for the width and height supports is planned for a follow-up after landing this initial version as it will also require creation of a shared preset input control to avoid reimplementing similar preset controls as the spacing sizes and border radius controls already have. I have something in the works on this front. As this PR stands I think it's ready for some initial reviews. One known issue is after the consolidation of block inspector and global styles panels, the default display of controls became out of whack. It still needs a fix on this PR or in a follow up. |
Member
|
Are the JSON snippets correct in the PR description? "dimensions": {
"width": true,
"__experimentalSkipSerialization": true, // this one
"__experimentalDefaultControls": {
"width": false
}
},We're not skipping serialization right? At least, it doesn't work until I remove that line 😄 Here's what I'm seeing when I do remove it: 2025-11-14.16.37.38.mp4 |
ramonjd
reviewed
Nov 14, 2025
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
Working pretty well for me so far. I ran out of time to go any deeper, but I tested the main stuff, theme/block/global styles.
Nice!
Contributor
|
Thanks for working on this! One concern is that it conflicts with "the width support as a child block". Their internal roles are different, of course, but visually you can't tell the difference. The items in the tool panel have also been unintentionally merged into one: 
Perhaps the new width support should be disabled when the block is in a flex layout? |
Contributor
I think so, yes. The Spacer block does this with its ad-hoc width and height controls, so there's a precedent. Arguably we might also want to disable these controls for children of grid layouts, because width/height in grids should really be set with column or row spans. But eliminating the duplication for flex children would be a good first step. |
aaronrobertshaw
force-pushed
the
add/width-height-block-supports
branch
from
bb1be96 to
4a7d2d5
Compare
aaronrobertshaw
force-pushed
the
add/width-height-block-supports
branch
from
4a7d2d5 to
63a31d3
Compare
Contributor
|
Thanks for all the reviews and testing everyone 🙇 I've addressed most feedback and resolved the conflicts.
Sorry, I meant that snippet as an example that illustrated all the different config options that would be needed for testing. I've updated the PR description to flag that.
At the moment, this block support won't be adopted immediately by current core blocks (just new ones in dev e.g. Icon block). I was hoping that addressing this could be a quick follow up to this PR. The Spacer block might provide some clues for the application of support styles for static blocks based on the parent layout. Likewise, the handling of aspect ratio vs min-height styles on the PHP side may guide how we can dynamically opt out of or strip the support styles. While I've started exploring this angle so width support plays nicer with layouts, it needs more time. Meanwhile, though, how comfortable would everyone be merging and iterating here? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR introduces
dimensions.widthto the list of available block supports.dimensions.heightis being added in #71914Blocks that have a
widthattribute:Why?
Part of the work being done in #71227 is to remove the custom width and height controls in favor of customizations via block supports. As we'll need width and height controls for the icons, this PR adds them.
How?
Extending the existing
dimensionssupports object.Testing Instructions
widthblock support for both a static and dynamic block (e.g. paragraph & cover) via their block.json filessettings.dimensions.width: falseExample block.json dimensions config that cover multiple test scenarios. Tweak as required e.g. removing skipping serialization:
Example theme.json width styles:
Demos
The video below demonstrates a Cover block with width block support opted into. First, a global style is set to apply a consistent width to Cover blocks. This is then overridden by the block instance applying a width support style.
Screen.Recording.2025-11-14.at.12.01.29.am.mp4