Add height block support to dimension #71914
Merged
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
requested review from
ellatrix,
spacedmonkey and
tellthemachines
as code owners
ryanwelcher
added
[Type] Enhancement
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 6.9 Editor Tasks
9 tasks
|
Size Change: +228 B (+0.01%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
Contributor
Author
|
A quick scan of the block shows the following blocks that have a
|
|
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. |
Contributor
aaronrobertshaw
left a comment
aaronrobertshaw
left a comment
There was a problem hiding this comment.
Thanks for putting this one together 🙇
After a quick glance at this PR, it shares some issues with the related width support PR - #71905.
I've left a couple of quick comments below that might help refine the approach here.
I hope that helps.
packages/block-editor/src/components/global-styles/dimensions-panel.js
Outdated
Show resolved
Hide resolved
Contributor
|
We are going to punt the Icon Block to 7.0, so we might want to change the status of this PR as well. |
t-hamano
moved this from 🔎 Needs Review
to 🦵 Punted to 7.0
in WordPress 6.9 Editor Tasks
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
beb1bce to
e2cf62f
Compare
aaronrobertshaw
requested review from
ajitbohra,
fabiankaegy and
juanmaguitar
as code owners
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
e2cf62f to
5cf3c3c
Compare
|
Flaky tests detected in badf4ff. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20150012523
|
aaronrobertshaw
changed the base branch from
trunk
to
add/width-height-block-supports
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
5cf3c3c to
b29ff4f
Compare
aaronrobertshaw
force-pushed
the
add/width-height-block-supports
branch
from
3cfabac to
bb1be96
Compare
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
2 times, most recently
from
c4727c2 to
80a1ef7
Compare
Contributor
|
I've added a quick demo of the current height 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. |
aaronrobertshaw
force-pushed
the
add/presets-to-width-support
branch
from
f11ac4f to
2843130
Compare
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
1d249ca to
fb034e8
Compare
Contributor
|
Thanks for the speedy review @ramonjd 👍
I believe it will need that tweak. It's on my list but I needed to improve some aspects of the underlying PR extracting the PresetInputControl component first. That's been done and this PR rebased now too, so I'll circle back to this |
Contributor
|
I've added the same handling for |
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
7292898 to
4cd95fd
Compare
youknowriad
reviewed
Dec 11, 2025
| inlineStyleOverrides.minHeight = 'unset'; | ||
| } else if ( minHeight || style?.dimensions?.minHeight ) { | ||
| // To ensure the minHeight does not get overridden by `aspectRatio` unset any existing rule. | ||
| inlineStyleOverrides.height = 'unset'; |
Contributor
There was a problem hiding this comment.
I wonder why we're doing these things at the rendering level, can't we "unset" in the UI? Or do we even need to be this smart? (Maybe we do, just asking)
Contributor
There was a problem hiding this comment.
I don't have full context on the original decision to handle this in this manner but @andrewserong might be able to shed further light.
The PR introducing aspect ratio support was #56897 and details the following for the "why" behind it.
This PR tries to let the CSS aspect-ratio work the way that it works, with minimal interference. To achieve this, and to avoid overflow issues, when an aspect ratio is set, we unset any value for min-height. Similarly, if a min-height is set at the block level, we output an aspect-ratio: unset rule to override any aspect ratio set in global styles. These unset rules should only be output for blocks that opt-in to aspect ratio, and are not saved to post content.
Before seeing that, my understanding was that the chosen approach was based on the block inspector not having access to the full set of global styles or third-party stylesheets. Now that global styles data is available in the post editor, most use cases should be addressable directly through the UI.
This also relates to how style inheritance is handled in the inspector. With those values exposed, the UI could more reliably determine things like aspect ratio versus min-height versus height, even if theme-enqueued stylesheets remain outside that scope.
Overall, the current approach seems slightly more robust.
Contributor
|
This is looking good, how feasible is it to migrate the existing blocks with "height" attributes? (follow-ups probably) |
Contributor
It's definitely coming along 👍 You're right, any migrations of blocks should be separate follow-ups. They'll all need to involve deprecations, which always tend to be a pain and uncover incorrect deprecations made in the past that need fixing. Separate follow ups should make for easier reviews and splitting up the work. As for the feasibility of migrating blocks, I don't see any blockers at this stage. It'll be nice to see all the ad hoc height solutions consolidated. Same for widths, etc, too. |
aaronrobertshaw
force-pushed
the
add/presets-to-width-support
branch
from
2843130 to
818cfe7
Compare
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
4cd95fd to
badf4ff
Compare
aaronrobertshaw
force-pushed
the
add/presets-to-width-support
branch
from
0c6a323 to
f55f845
Compare
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
badf4ff to
66c1d6a
Compare
Contributor
|
The two PRs forming the basis for this PR have been merged. So this should be ready for another review. |
ramonjd
approved these changes
Dec 16, 2025
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
Nice work here, thanks for sticking with it for the back and forth.
- block styles work and override global styles
- global styles override theme.json
- theme.json settings and block styles work
- controls appear when and where they should 😄
Obligatory screenshot.
Just had a question about a potential UX follow up otherwise LGTM
packages/block-editor/src/components/global-styles/dimensions-panel.js
Outdated
Show resolved
Hide resolved
github-project-automation
bot
moved this from 🦵 Punted to 7.0
to ✅ Done
in WordPress 6.9 Editor Tasks
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.
Based on:
What?
This PR adds
heighttodimensionsblock supports. This was split out from #71905.Blocks wth
heightattributes: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. This PR handles the
heightblock supports portion.How?
Extending the existing
dimensionssupports object.Testing Instructions
heightblock support for both a static and dynamic block (e.g. paragraph & cover) via their block.json filessettings.dimensions.height: falseExample block.json dimensions config:
Example theme.json height styles:
Demos
The video below demonstrates a Cover block with height block support opted into. First, a global style is set to apply a consistent height to Cover blocks (note Cover blocks also have a default min-height). This is then overridden by the block instance applying a height support style.
Screen.Recording.2025-11-14.at.12.05.50.am.mp4