Prevent images from appearing squished when only one dimension is set

[lschuyler]

This PR addresses the issue of images in the editor appearing squashed when only one dimension is set.

Problem

When you set only one of the image block's dimensions (width or height) in the editor and leave the other blank (auto), Gutenberg serializes just that single value as an inline style, like this:

<img 
  src="…blue-shape.png" 
  alt="blue-shape.png" 
  style="width: 64px;" 
  width="228" 
  height="228" 
/>

In this example, the blue-shape.png image was uploaded at 228 x 228. In the block editor UI, the width was set to 64px, and the height was left as auto.

Because many themes (like the one we were using when we discovered this) still define a fixed CSS height (in our case, 76px), the browser will render the image at 64 x 76, making it appear distorted.

In this example, this was the existing CSS:

.is-style-features-page-three-column-block_img img {
  width:  76px;
  height: 76px;
}

This Fix

This PR adds similar logic in two places to ensure that whenever only one dimension is set by the user, the other dimension is explicitly set to auto, to preserve the aspect ratio.

This logic is added in two places:

1. Editor rendering (packages/block-library/src/image/image.js)
2. Front-end save output (packages/block-library/src/image/save.js)

In each file, a small style object is built that:

• Emits width: XXpx only if the user explicitly provided a width.
• Emits height: auto when height is unset or explicitly set to "auto", blocking any theme CSS height.
• Emits height: XXpx only when the user set a numeric height.

By guaranteeing height: auto whenever height isn't defined, this prevents themes' CSS heights from squashing the image. A theme's default width remains in effect when the user hasn't adjusted the width in the editor.

Handling Existing Content

A new deprecation (v9) is added to handle image blocks that were saved before this fix with only width set and no height in the inline style. When one of those blocks is next saved, it will be migrated so the inline style includes height: auto. Integration test fixtures are included covering parse and serialisation of this migration path.

Testing Instructions

1. Before you put this PR in place, go to Appearance -> Editor -> Design -> Styles -> CSS and add a new style definition for the image you are about to add:

.image-test img {
	width: 76px;
	height: 76px;
}

2. Create a new page.
3. Insert an image block (select any image from your Media Library) and set the width to a number (example 64) and leave the height blank.
4. While that image is still selected, expand "Advanced" and add the image-test class.
5. Notice the image dimensions. Save the page and view it (outside of the editor). Right click and select "Inspect" to see the inline style. The image will appear compressed.
6. Put this PR in place and try resetting the dimensions in the editor UI again for this image by setting the width to 50 and leaving the height unset (or set to auto).
7. Repeat step 5. This time, the image won't appear compressed.

Screenshots (inside the Editor)

Before the fix (64 x 76):

After the fix (64 x 64):

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: lschuyler <lschuyler@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[lschuyler]

Update after rebasing on trunk.

This has been rebased and reworked since the original submission. Main changes:

• The fix is now conditional — height: auto is only applied inline when width is set and height is not (and vice versa), rather than always writing both dimensions.
• A v9 deprecation has been added so that existing posts with only width set are migrated correctly on re-save rather than triggering a block validation error.
• Integration test fixtures are included for the deprecation path.

[aaronrobertshaw]

Thanks for the work on this @lschuyler 👍

This is testing pretty nicely for me.

For others looking at the deprecation, it's worth noting that the structure in this PR is correct. As older deprecations would match on their outdated markup, they'd get resaved to acquire the height: auto inline style as needed. Given there is no migration of attributes required, only the new v9 deprecation is needed.

While reviewing the deprecations I think I spotted one issue with v7.migrate(). With the unconditional template literal, a block with width: 300, height: undefined migrates to height: "undefinedpx". The new current save() then serializes that literally as style="height: undefinedpx".

The v6.migrate() function handles this better.

The bug there predates this PR but this one does make it worse. So I think we should fix it up now. Additionally, it's just nice whenever adding a new version for a block to ensure every past version is migrated correctly to the latest and greatest.

One other thing, is the isEligible check actually needed? It's conventionally for attribute schema only migrations where the block markup is technically still valid but the attributes still need migrating. I feel isEligible here might be redundant and slightly misleading.

More practically: after a block is migrated and re-saved with the new format, the height attribute is still undefined (it's never stored), so isEligible would keep returning true on every subsequent load. With no migrate() this is a no-op, but it means the deprecation system needlessly processes the block on every parse. Worth dropping isEligible from v9 entirely since the save() match handles it.

[lschuyler]

Thanks for the thorough review @aaronrobertshaw! I pushed another commit to address your feedback:

• Fixed v7.migrate() to guard with typeof width === 'number' before appending 'px', matching the pattern already used in v6.migrate().
• Removed isEligible from v9. You're right, that it was redundant and would have caused unnecessary reprocessing on every parse.

[aaronrobertshaw]

The tweaks to the deprecations look good, thanks @lschuyler 🚀

This PR is testing as advertised for me.

Before	After

LGTM 🚢

[youknowriad]

@aaronrobertshaw any reason this was not merged when the PR was approved?

[ramonjd]

I just re-tested this. Thanks for rebasing @lschuyler

It's working well for me. I can merge it.

[aaronrobertshaw]

@aaronrobertshaw any reason this was not merged when the PR was approved?

Apologies for the slow reply while away. I have a vague recollection of re-running a failed test. Looks like I missed hitting auto merge 😬