Add width block supports under dimensions. #71905
Conversation
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. |
| function useHasWidth( settings ) { | ||
| return settings?.dimensions?.width; | ||
| } | ||
| function useHasHeight( settings ) { | ||
| return settings?.dimensions?.height; | ||
| } |
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.
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.
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.
There was a problem hiding this comment.
I've renamed the function to something more appropriate in this PR #71905 71914
|
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
|
Absolutely. I'll get two PRs in place. Do you want the block updates to be in the PR for each new support? |
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
|
I've split the |
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 6.9 Editor Tasks
|
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? |
|
P.S. It seems that @aaronrobertshaw did something similar about four years ago: #32502 |
|
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) |
|
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. |
It @aaronrobertshaw wants to pick that up again, I'm happy to close this PR in favor of his. |
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
|
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? |
|
Thanks for the update! I think this PR works very well. They're not blockers, but here are some questions I have at the moment:
|
Are there any sensible defaults we could use for the icon block when width support is disabled? Maybe the icon block could have it turned on by default in lib/theme.json? |
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
I think this is a great start, thanks for working on it folks and getting the foundation into shape.
I'm assuming blocks that skip serialization like core/search will need special treatment in follow ups as they adopt the support.
I wasn't sure... does gutenberg_render_dimensions_support need to handle width?
Yes, we might want some default values, like this: .wp-block-icon svg {
width: 1em;
height: 1em;
}
While this approach is possible, it means that we won't be able to disable width support at the root level. This means that a theme.json like the one below won't work correctly. In some ways, this is expected, but this behavior has been reported as a bug in the past. See #54858 This concern isn't a blocker, but we wanted to raise it as we work to improve width support in the future. |
|
Thanks again for all the discussion, reviews, and testing.
Agreed. There's benefit in providing the util, it's on the cards. I left it as a separate follow-up as it will need to also cover the other dimensions supports that ignored this too e.g. minHeight, aspectRatio etc.
From experience default styles have proven problematic at times but I'm not against them here.
This would get my vote.
I don't see this as an issue. As you note, this is working as expected, and there are several precedents for other blocks closely tied to different supports, e.g. button with border radii, image lightboxes, and pullquote borders. Even if a theme author wishes to disable width support globally and does in fact mean to remove it from blocks that sort of depend on it. It isn't that it's impossible, just that the theme author has to deliberately disable it for those blocks.
Any block that requires styles to be placed on a custom element by nature needs some special treatment and an update. It's the same as adopting any other block support on a block with similar needs.
The render callback for this support was specifically fudging styles from minHeight and aspectRatio supports. This was due to their unique relationship. For a normal block support that simply and independently applies its styles it should only be done within the apply callback. This makes the result filterable and consistent with other block supports. The original form of this PR actually made the small mistake of updating the render call back instead. |
|
From the latest discussion I don't believe there are any blockers to merging this and we can tweak anything required in follow-ups. I'll get this merged to allow for multiple follow-ups to occur in parallel including:
|
github-project-automation
bot
moved this from 🦵 Punted to 7.0
to ✅ Done
in WordPress 6.9 Editor Tasks
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