Dimensions Support: Add dimension presets and adopt for width and min height block supports #73811
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
aaronrobertshaw
added
[Type] Enhancement
|
Size Change: +86 B (0%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
8 tasks
4 tasks
aaronrobertshaw
force-pushed
the
add/preset-input-control
branch
from
06744b2 to
f4e0acf
Compare
aaronrobertshaw
force-pushed
the
add/presets-to-width-support
branch
from
f11ac4f to
2843130
Compare
Contributor
Author
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
I might not get time to test this properly before I wrap up for some AFK, so this is just a drive-by comment that the approach and code change generally looks good to me, and adding in these presets is a much-needed feature. Also, I like the subtle naming choices to go with the singular dimensionSizes rather than the awkward double 's' of dimensionsSizes.
This next section is rambling as I'm trying to capture a thought. There is nothing that needs actioning from the following questions/thoughts:
One question I had from looking over the change, and this isn't at all a blocker as we can easily have a similar question when looking at spacingSizes:
How might we eventually support a different set of presets based on a more granular single dimension. I.e. let's say a theme might want large or sparse presets for minHeight, thinking of presets for a larger area like a Group block that might fill up 25%, 50%, or 100% of the viewport height. Whereas for width, they might be thinking of the icon block, and want smaller sizes like 16px, 24px, 32px, etc.
This question can also get a bit absurd if we start to think about it at a per-block level within theme.json so that different blocks could have different presets.
Perhaps, eventually, we might support nesting dimensionSizes within other properties, i.e. dimensions.minHeight.dimensionSizes as a more granular version of the presets.
In any case, that's a future problem, but mostly I wanted to ask the question in case it informs anything now, or as food for thought.
Other than that, I think I found one line where we might want to keep a little back-compat in case anyone's been using spacing preset CSS vars for minHeight? Possibly unlikely, though.
Otherwise this is looking pretty good to me!
| 'path' => array( 'dimensions', 'minHeight' ), | ||
| 'css_vars' => array( | ||
| 'spacing' => '--wp--preset--spacing--$slug', | ||
| 'dimension' => '--wp--preset--dimension--$slug', |
Contributor
There was a problem hiding this comment.
Tiny nit: should we retain both of these lines? So include both spacing and dimensions in this list, so that any existing themes or sites that reference the spacing preset can continue to output styles for that?
I'm not 100% certain, but I think the code will loop through the css_vars until it finds a match, from a quick look at:
Apologies if this is way off!
Contributor
Author
There was a problem hiding this comment.
I'm not 100% sure. Did minHeight support ever actually support presets? It seemed like this was copy and pasted config that never got updated, used, or cleaned up. Could totally be wrong of course.
To me, this looked like a bug. The overloading of spacing presets has also always looked wrong.
Contributor
Author
There was a problem hiding this comment.
We can keep both lines, probably putting the "preferred" presets first i.e. dimensions. I think, though, if it is unlikely that presets were ever used for min height support, I'd probably lean towards cleaning this up as a bug fix.
Contributor
Author
Good question @andrewserong 👍 We actually already have the possibility for individual blocks to define their own settings via an inline theme.json object. I suspect we could possible leverage that or something similar for block type or block level presets. Like in the Icon block example you raised. As for differing, presets for individual dimensions etc, we could look to nest the presets as you suggested. Another option would be to add a I feel pretty comfortable that this can all be addressed in a follow-up. |
aaronrobertshaw
force-pushed
the
add/presets-to-width-support
branch
from
2843130 to
818cfe7
Compare
|
Flaky tests detected in 818cfe7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20149894318
|
Member
Interesting idea. Agree it can be a follow up. Something like this could be forward compatible too, maybe a bit fugly {
"settings": {
"dimensions": {
"dimensionSizes": [
// General presets (fallback for all dimension properties)
{ "name": "Small", "slug": "small", "size": "240px" },
{ "name": "Medium", "slug": "medium", "size": "480px" }
],
"widthSizes": [
// Width-specific presets (for icon blocks, etc.)
{ "name": "Tiny", "slug": "tiny", "size": "16px" },
{ "name": "Small", "slug": "small", "size": "24px" },
{ "name": "Medium", "slug": "medium", "size": "32px" },
{ "name": "Large", "slug": "large", "size": "48px" }
],
"minHeightSizes": [
// Min-height-specific presets (for Group blocks, etc.)
{ "name": "Quarter Viewport", "slug": "quarter-vh", "size": "25vh" },
{ "name": "Half Viewport", "slug": "half-vh", "size": "50vh" },
{ "name": "Full Viewport", "slug": "full-vh", "size": "100vh" }
]
}
}
} |
ramonjd
reviewed
Dec 12, 2025
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
This working well for me in my testing.
Let me know if there's anything specific you'd like tested.
packages/block-editor/src/components/dimension-control/README.md
Outdated
Show resolved
Hide resolved
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.
Related:
What?
Why?
Improves the UX so that users don't have to manually ensure consistent sizes across applications of dimensions support.
How?
Testing Instructions
dimension.dimensionSizespresets to your theme.json file8 Test applying custom values when the control has the custom select list view
Example Theme.json Presets Config
Reduce the number of presets to < 8 to test slider control.
Screenshots or screencast
Screen.Recording.2025-12-08.at.2.16.27.am.mp4