Since 6.3, the display ratio of images is broken when the size of the Image Block is specified.

[ddryo]

Description

A specification change regarding the behavior when width and height are specified is causing the problem.

Previously, the size was only output in the width and height attributes. (e.g. width="..." height="...")

However, starting with 6.3, the style attribute suddenly overrides the numerical value in px units. (e.g. style="width: ...px;height: ...px")

This will cause images that have already been installed in the past to be displayed incorrectly.

Example

Take a 960px:640px size image file as an example.

• If 75% is specified in v.6.2, the width and height attributes will be 720:480 respectively.
  (<img width="720" height="480" ...>))
• In v.6.3, the width and height will be set to 720px and 480px, respectively, in the style as well as the attribute values.
  (<img width="720" height="480" style="width:720px;height:480px" ...>)

In most cases, <img> applies max-width:100%;height: auto;. (The core style is also like that. )
However, since v.6.3, the height is forced to be overridden by the px value, which overrides the height:auto, and the proportions are quite broken when viewed at phone sizes, etc.

Making this change suddenly after 4 years would cause a lot of problems.

Problems with the "ASPECT RATIO" setting

This is a slightly different issue, but along with the above problem, there was something else that bothered me.

In v.6.3, "ASPECT RATIO" is displayed as "Custom" when width and height are specified.

This is disconcerting.

For example, when the width is 400px and the height is 200px, the "Custom" label makes me think that aspect-ratio=400/200 would be output.

However, in reality, aspect-ratio is not outputted in any way.

Isn't the expression "None" instead of "Custom"?

Step-by-step reproduction instructions

Please specify the width and height in the Image Block.

Screenshots, screen recording, code snippet

Here is a screenshot with the TT3 theme.

↓Smartphone display in version 6.2 when 75% is specified for images

.

↓Images that had 75% specified for the image are collapsing after the update

Suggestion for improvement

• The width and height settings as of 6.3 should only output width and height in the attribute values as before, and output aspect-ratio in the style. Then, the "ASPECT RATIO" should be indicated as "Custom".
• The setting for setting width and height as px values in the style attribute should be prepared separately. In this case, the "ASPECT RATIO" should be expressed as "None".

---

Environment info

• WordPress 6.3
• TT3

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[laurelfulford]

I've run into this issue but with images added after the 6.3 update. The steps to recreate are:

1. Add an image block and insert an image.
2. Use the handles on the image to resize (not the inputs in the sidebar).

When you use the handles, the "Scale" option isn't updated to select Cover or Contain, so you end up with only the height and width added in the style attribute.

Editor after scaling down the image a bit:

Front-end:

I can recreate this with TT3 and WordPress 6.3, and TT3 and Gutenberg v 16.4.0.

[ddryo]

It seems to me that we can address this issue by setting height:auto !important, but we need to be careful.

This would affect the user specifying the image size with CSS.

For example, if the user adds a class .small-img to the Image Block and writes the following CSS.

.wp-block-iamge.small-img{
    width: 80px;
    height: 80px;
}

[ddryo]

As a hasty countermeasure, I took the following approach within my theme.

add_filter( 'render_block_core/image', __NAMESPACE__ . '\fix_img_v63', 10, 2 );
function fix_img_v63( $block_content, $block ) {
	$attrs = $block['attrs'] ?? [];
	$w = $attrs['width'] ?? '';
	$h = $attrs['height'] ?? '';
	if ( $w && $h ) {
		$size_style    = "width:{$w}px;height:{$h}px";
		$ratio         = "{$w}/{$h}";
		$block_content = str_replace( $size_style, "aspect-ratio:{$ratio}", $block_content );
	}
	return $block_content;
}

Note: If we want to be strict, you should extract the style attribute in the img tag with a regular expression and then add the processing, but the description width:{$w}px;height:{$h}px usually only appears in the style in the img, so I am dealing with it briefly.

[t-hamano]

It turns out that this problem also occurs on Twenty Twenty-Two. I haven't made any changes, but the header image is overflowing.

Originally, it should be displayed as shown below.

From my understanding, this bug occurred in WP6.3. I think this is an issue that should be resolved in WP6.4, so I'll add it to the project board.

[annezazu]

We're cutting this very close to the beta 1 for 6.4. Once beta 1 happens, only bugs introduced in 6.4 can be resolved and I don't see this being fixed by then. As a result, I'm moving to 6.4.1 at the earliest.

[ajlende]

I'm seeing a few separate issues discussed here.

1. [T]he style attribute suddenly overrides the numerical value in px units. ... This will cause images that have already been installed in the past to be displayed incorrectly. [comment]

   This sounds like an issue with the block deprecation added in Image block: Fix stretched images constrained by max-width #53274. It causes existing images with width and height attributes to use pixel values instead.

   The HTML specification says that the dimensions attributes are intended to be used as hints for rendering, but Gutenberg was using them as styling controls. In #53274, migrating the attributes to be more semantically correct for HTML by adding them to CSS instead. However, the semantically correct CSS dimensions interact with max-width specified in many themes causing the layout to change from what it was before.

   In some situations, the solution that @ddryo recommended will work. However, that won't work everywhere. To get it working in all cases, you'd have to know the constraining dimension (most often the width) and add that in addition to the aspect-ratio. Unfortunately, we can't know the constraining dimension from the context available, so we probably need to migrate the old width/height attributes to deprecatedWidth/deprecatedHeight attributes that continues to set the img attributes instead of converting them to CSS styles in order to completely preserve the previous behavior.

2. It turns out that this problem also occurs on Twenty Twenty-Two. I haven't made any changes, but the header image is overflowing. [comment]

   I checked the image in TT2, and it looks like it's in an invalid state. It specifies width and height attributes despite not being a resizable image due to the wide alignment.

   I'm not sure if it was possible to get in this state using the editor only previously, and TT2 should be updated to remove the block attributes. If it was a valid configuration at some point, we might want to properly handle the deprecation.

   That being said, I think the solution proposed above will fix this specific issue. Also worth noting that there is an issue for supporting dimensions on wide and full images Add support for aspect ratio on wide and full images #53652.

3. I've run into this issue but with images added after the 6.3 update. ... When you use the handles, the "Scale" option isn't updated to select Cover or Contain, so you end up with only the height and width added in the style attribute. [comment]

   From your screenshots, I think the problem you're trying to describe isn't so much about automatically setting the scale option as it is about aspect ratio not being maintained with max-width set after using the drag handles due to max-width being set by the theme.

   We specifically don't set the scale option to maintain the behavior from before where the image could be stretched. You don't really want to set scale contain by default because, while the image will have it's aspect ratio maintained, the element will still take up the same amount of space as when it was stretched and the extra space will just be empty.

   I opened Drag to resize image doesn't maintain aspect ratio when constrained #55624 to track this. Feel free to update the description if I got anything wrong and continue discussion there.

4. "ASPECT RATIO" is displayed as "Custom" when width and height are specified. [comment]

   The "Aspect ratio" dropdown doesn't correspond directly to the aspect-ratio CSS, and this is by design. Setting a width and a height will necessarily constrain the aspect ratio for the image to a custom aspect ratio. Setting both a CSS width and height would override whatever is set in an aspect-ratio property anyway.

[josefinemk]

Hey, I just want to pitch in here as well.

I’ve had so many issues with my images since the WordPress 6.2. update this summer! I've reached out to several developers and no one can fully troubleshoot the issue.

And the issue is the fact that I'm missing the feature where I can select the image to be 25%-50%-75%-100% of the image size. That's it. Why did you have to remove that?

Instead, now I have to manually type the width and height in pixel and then after that I have to select ‘contain’ under scale — instead of just clicking one button. (This creates a border around the image so it takes up lots of screenspace and does not look good either)

This is rather annoying – but the bigger issue is that ALL of my previous 300 posts now have distorted images on mobile because this feature is gone. This is negatively impacting my SEO.

I have to go through the posts 1 by 1 to then manually set the width and height in pixels and then click ‘contain’.

There’s gotta be a better way?

Could you please just bring back the % feature? Please :)