Add height block support to dimension #71914
Open
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: +151 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.
lib/block-supports/dimensions.php
Outdated
| $has_aspect_ratio_support = block_has_support( $block_type, array( 'dimensions', 'aspectRatio' ), false ); | ||
| $block_type = WP_Block_Type_Registry::get_instance()->get_registered( $block['blockName'] ); | ||
| $block_attributes = ( isset( $block['attrs'] ) && is_array( $block['attrs'] ) ) ? $block['attrs'] : array(); | ||
| $has_dimensions_support = block_has_support( $block_type, 'dimensions', false ); |
Contributor
There was a problem hiding this comment.
Similar to the feedback left over on #71905, these changes alter the logic as to when the aspect ratio/min height overrides occur. I don't think this was intended.
lib/block-supports/dimensions.php
Outdated
Comment on lines
113
to
115
| // Add height value. | ||
| $dimensions_block_styles['height'] = $block_attributes['style']['dimensions']['height'] ?? null; | ||
|
|
Contributor
There was a problem hiding this comment.
I think this might be better done via the gutenberg_apply_dimensions_support function where the block support attributes are first collected, allowing them to be filtered further by extenders.
Comment on lines
83
to
85
| function blockHasHeight( settings ) { | ||
| return settings?.dimensions?.height; | ||
| } |
Contributor
There was a problem hiding this comment.
Nit: The naming here would probably benefit from being consistent with the other functions checking the dimensions settings e.g. useHasAspectRatio.
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 0274422. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19664504132
|
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/height-block-supports
branch
from
80a1ef7 to
1d0cda4
Compare
Contributor
|
I've resolved the conflicts on this PR and added some unit tests for the application of height block support styles to match feedback provided on the width block support over in: #71905 (comment) This one might be ready for some testing too and review too. That is assuming we are ok merging and iterating these dimension block supports so they play nicer with layout supports like flex and grid. |
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
091e73d to
0274422
Compare
Contributor
|
I've rebased again after the initial width block support PR has been merged. There are some follow-ups flagged for these dimensions supports. A quick list can be found via #71905 (comment) |
ramonjd
reviewed
Nov 27, 2025
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
This is working well out of the box. Thanks for all the work here.
I rebased on top of #71905 to check the controls and operability between width and height. Things work as I'd expect:
Theme.json and block styles combine for some funky designs!
I'm just not sure whether height needs the same treatment as minHeight in relation to aspectRatio.
Maybe it's been answered elsewhere sorry.
| export default { | ||
| useBlockProps, | ||
| attributeKeys: [ 'minHeight', 'width', 'style' ], | ||
| attributeKeys: [ 'height', 'minHeight', 'width', 'style' ], |
Member
There was a problem hiding this comment.
Just checking: do we need to add logic similar to what's below (around line 201) for minHeight to handle height + aspectRatio conflicts?
E.g., unsetting height when aspectRatio is set, or vice versa?
Contributor
There was a problem hiding this comment.
Yeah, quite possibly. I'll work on updating that soon.
| <HeightControl | ||
| label={ __( 'Height' ) } | ||
| value={ heightValue } | ||
| onChange={ setHeightValue } |
Member
There was a problem hiding this comment.
Similar to question above. setMinHeightValue removes any applied aspect ratio. Is that required here too?
And if so, does it need handling in gutenberg_render_dimensions_support?
8 tasks
aaronrobertshaw
force-pushed
the
add/height-block-supports
branch
from
626565c to
1d249ca
Compare
aaronrobertshaw
changed the base branch from
trunk
to
add/preset-input-control
aaronrobertshaw
changed the base branch from
add/preset-input-control
to
add/presets-to-width-support
Contributor
Member
|
I retested with block and theme.json, also with aspect ratio support applied: Kapture.2025-12-10.at.15.13.05.mp4Working very well. I'm not sure if aspect ration needs to be unset if there's a height value similar to how I'm guessing so for consistency? 🤷🏻 Is there something specific to test? In general things are looking 👍🏻 |
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
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