WordPress.org

Make WordPress Core

Opened 7 weeks ago

Last modified 2 weeks ago

#50909 new defect (bug)

WordPress 5.5 update adds height and width attributes to images

Reported by: jeslen Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.5
Component: Media Keywords: close 2nd-opinion
Focuses: Cc:

Description

It appears that some images added with the gutenberg editor (no updates since June) now have height and width attributes being dynamically added following the new loading attribute.

I updated locally only so far.

This is the previous img element being displayed in the browser:

<img src="https://www.brothersmoving.local/wp-content/uploads/2020/06/AdobeStock_230714251_Preview.jpeg" alt="Adobestock 230714251 Preview" class="wp-image-8050" srcset="https://staging.brothersmoving.ca/wp-content/uploads/2020/06/AdobeStock_230714251_Preview.jpeg 1000w, https://staging.brothersmoving.ca/wp-content/uploads/2020/06/AdobeStock_230714251_Preview-300x134.jpeg 300w, https://staging.brothersmoving.ca/wp-content/uploads/2020/06/AdobeStock_230714251_Preview-768x344.jpeg 768w" sizes="(max-width: 1000px) 100vw, 1000px">

This is it now:

<img loading="lazy" width="1000" height="448" src="https://www.brothersmoving.local/wp-content/uploads/2020/06/AdobeStock_230714251_Preview.jpeg" alt="Adobestock 230714251 Preview" class="wp-image-8050" srcset="https://www.brothersmoving.local/wp-content/uploads/2020/06/AdobeStock_230714251_Preview.jpeg 1000w, https://www.brothersmoving.local/wp-content/uploads/2020/06/AdobeStock_230714251_Preview-300x134.jpeg 300w, https://www.brothersmoving.local/wp-content/uploads/2020/06/AdobeStock_230714251_Preview-768x344.jpeg 768w" sizes="(max-width: 1000px) 100vw, 1000px">

These are the new attributes being added:

 loading="lazy" width="1000" height="448"

Attachments (2)

before.png (333.8 KB) - added by jeslen 7 weeks ago.
Before the update
after.png (482.6 KB) - added by jeslen 7 weeks ago.
after the update

Download all attachments as: .zip

Change History (26)

@jeslen
7 weeks ago

Before the update

@jeslen
7 weeks ago

after the update

#1 @davidbaumwald
7 weeks ago

  • Component changed from General to Media

#2 @joyously
7 weeks ago

There were two separate changes in 5.5. One added lazy load and the other added width and height to images that don't have them.

#3 follow-up: @jeslen
7 weeks ago

https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/

This states that only images that already have both the width and height attributes set will have the lazy-loading applied. That's not the case here. Images without width or height are having them applied as well as the loading attribute. This is breaking site layouts more than a layout shift would.

#4 @davidbaumwald
7 weeks ago

  • Severity changed from critical to normal

Related changeset: [48237]

This ticket was mentioned in Slack in #core-media by david.baumwald. View the logs.


7 weeks ago

#6 in reply to: ↑ 3 ; follow-up: @flixos90
7 weeks ago

Replying to jeslen:

https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/

This states that only images that already have both the width and height attributes set will have the lazy-loading applied. That's not the case here. Images without width or height are having them applied as well as the loading attribute. This is breaking site layouts more than a layout shift would.

Images will also receive width and height attributes where that information is available. Would you be willing to share which theme you are using? Typically themes should specify CSS rules such as max-width: 100%; height: auto to avoid this kind of overflowing.

#7 in reply to: ↑ 6 @jeslen
7 weeks ago

Replying to flixos90:

Replying to jeslen:

https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/

This states that only images that already have both the width and height attributes set will have the lazy-loading applied. That's not the case here. Images without width or height are having them applied as well as the loading attribute. This is breaking site layouts more than a layout shift would.

Images will also receive width and height attributes where that information is available. Would you be willing to share which theme you are using? Typically themes should specify CSS rules such as max-width: 100%; height: auto to avoid this kind of overflowing.

This one in particular is a child theme based on Timber's starter child theme and built with Bootstrap.

The images are being displayed via the Gutenberg editor with the wp-block-styles theme support added. I can see that .wp-block-image img {max-width: 100%} is set. It might be helpful to add the height: auto style here as well.

Last edited 7 weeks ago by jeslen (previous) (diff)

#8 follow-up: @pbgeneral
7 weeks ago

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

#9 in reply to: ↑ 8 ; follow-ups: @jeslen
7 weeks ago

Replying to pbgeneral:

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

Adding this CSS should resolve the issue.

img {
  max-width: 100%;
  height: auto;
}

Although I'm not sure if this will prevent the height attribute from working in scenarios where that is preferred.

#10 in reply to: ↑ 9 ; follow-up: @pbgeneral
7 weeks ago

Replying to jeslen:

Replying to pbgeneral:

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

Adding this CSS should resolve the issue.

img {
  max-width: 100%;
  height: auto;
}

Although I'm not sure if this will prevent the height attribute from working in scenarios where that is preferred.

Thanks. I'm not a tech person — what do you mean? Will there be unintended side effects from this?

#11 @joyously
7 weeks ago

CSS overrides attributes.

#12 in reply to: ↑ 10 @jeslen
7 weeks ago

Replying to pbgeneral:

Replying to jeslen:

Replying to pbgeneral:

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

Adding this CSS should resolve the issue.

img {
  max-width: 100%;
  height: auto;
}

Although I'm not sure if this will prevent the height attribute from working in scenarios where that is preferred.

Thanks. I'm not a tech person — what do you mean? Will there be unintended side effects from this?

Certain attributes will override others. The image height attribute is overridden by the CSS style. So basically, if there was an image that was relying on the height attribute to set its height as something different than its actual size (e.g. the actual image file has a height of 100px, but the height attribute is 200), then this CSS will override that.

This is the reason why putting that CSS in will "fix" the image height attribute issue. It simply overrides the height attributes that have been applied with this update.

Last edited 7 weeks ago by jeslen (previous) (diff)

#13 in reply to: ↑ 9 ; follow-up: @tmrg
7 weeks ago

Experiencing the same issue on my site.

Jeslen - where exactly did you add that CSS code? To overall site or newpost page?

Replying to jeslen:

Replying to pbgeneral:

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

Adding this CSS should resolve the issue.

img {
  max-width: 100%;
  height: auto;
}

Although I'm not sure if this will prevent the height attribute from working in scenarios where that is preferred.

#14 in reply to: ↑ 13 @jeslen
7 weeks ago

Replying to tmrg:

Experiencing the same issue on my site.

Jeslen - where exactly did you add that CSS code? To overall site or newpost page?

Replying to jeslen:

Replying to pbgeneral:

I'm having precisely this issue. It has distorted the images on hundreds of my articles, so it's a pretty serious matter.

Adding this CSS should resolve the issue.

img {
  max-width: 100%;
  height: auto;
}

Although I'm not sure if this will prevent the height attribute from working in scenarios where that is preferred.


The Answer:

I'm going to explain my reasoning, and you can see if this makes sense for you and anyone else who stumbles across this answer.

TL;DR

Add it to the the very top, or very bottom of your stylesheet (if the top doesn't work). Alternatively, search to find the last instance of the img selector in your CSS, and add it there.

The Explanation:

CSS, a Cascading StyleSheet, is read by the browser top to bottom. If there are identical selectors in the same or other CSS files, whichever one is at the bottom will take priority. Stylesheets added to a page one after another will be treated as if they were just added on to the end of the first.

For example, if a stylesheet has img { max-width: 100%; height:auto; } and then the same stylesheet later has img { height: 100%; } (notice the heights are different), the browser will render all images with max-width: 100% and height: 100%.

What's happening here is the first img selector instance is setting both the max-width and height styles, but the second instance of img is overriding the height. The browser will render the max-width style set from the first instance (max-width: 100%) while the height is rendered from the second (height: 100%).

It should be noted that a more specific selector can take priority over these img selectors. For example, the CSS img.square { width: 100px; height: 100px; } will target HTML img elements with the square class assigned to them, like so <img class='square' alt='...' src='...' />. These images would then always be rendered with height: 100px even if this CSS statement appears earlier in the stylesheet than the others.

So, ideally you'll likely want to add the image fix img { max-width: 100%; height: auto; } as close to the top of the first loaded stylesheet. It's added to the top so that any further changes which are required by your theme can properly override these settings, if required.

Potential Problems:

CSS Unsets the Height

There is a likely rare use case where the img selector already exists within the CSS and unsets the height as so img { height: unset; }. This will override the height by removing any height styles that have been set higher up in the stylesheet. In this case, if you added the fix to the top of the stylesheet and notice that it's not working, you could try searching to see if an img selector already exists somewhere else within.

In a worst case scenario, you can add this to the bottom of the last loaded stylesheet to guarantee that these styles are always rendered by the browser.

Images Rely on Height Attribute

If your theme did not set the height on an img selector anywhere in the CSS, but used the height attribute on some HTML img element like so <img height='400' alt='...' src='...' />, this is going to be overridden by your CSS in the same way the later instances of the same img selector—and the more specific selectors—would override the styles by taking priority. This is why adding these CSS styles will "fix" the issue. The CSS will override the HTML height attribute.

The update is dynamically adding these attributes to the HTML img elements on the page. If this is distorting many of your images by stretching them, this CSS fix will be applied to all HTML img elements on your site, whether that is intended or not. Therefore, this could cause some weird behaviour for images that currently rely on the HTML img height attribute.

Last edited 7 weeks ago by jeslen (previous) (diff)

#15 @jeslen
7 weeks ago

Not sure if this should be considered a separate bug or the same one.

The Image dimensions setting in the Gutenberg editor no longer work if the CSS style height: auto; is applied to the img selector. So, any image that had its dimensions altered in Gutenberg, and were displaying appropriately, will now display incorrectly since the CSS takes priority.

#16 @SergeyBiryukov
7 weeks ago

#50938 was marked as a duplicate.

#17 @markusd112
7 weeks ago

We have the same problem on our website using the twentyten theme. Adding the above mentioned additional CSS in the themes customizer seems to fix the issue for us, hoping there are no hidden side effects that we haven't seen in the moment....

#18 @mgrza
6 weeks ago

Solved my issue, thanks.

Last edited 6 weeks ago by mgrza (previous) (diff)

#19 @aut0poietic
6 weeks ago

The (S)CSS controlling responsive images is part of Gutenberg's Image block's styles.

https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/image/style.scss#L6

Would it be better to add the height: auto; here?

#20 follow-up: @litemotiv
6 weeks ago

A problem for many sites lies in the fact that previously images in rows of columns automatically got the same height:

[5.4]

https://i.imgur.com/tD3HCJW.jpg

The new forced width and height attributes then stretch an image without height:auto in the css:

[5.5]

https://i.imgur.com/ygGYrA5.jpeg

Adding height:auto does fix the stretching, but it also causes all images to get different heights, making it impossible to create grids/rows of images with aligning heights:

[5.5 with height:auto]

https://i.imgur.com/pnIC0kE.jpg

So what would be the solution to restore that behavior?

Last edited 6 weeks ago by litemotiv (previous) (diff)

#21 in reply to: ↑ 20 @jeslen
5 weeks ago

Replying to litemotiv:

A problem for many sites lies in the fact that previously images in rows of columns automatically got the same height:

[5.4]

https://i.imgur.com/tD3HCJW.jpg

The new forced width and height attributes then stretch an image without height:auto in the css:

[5.5]

https://i.imgur.com/ygGYrA5.jpeg

Adding height:auto does fix the stretching, but it also causes all images to get different heights, making it impossible to create grids/rows of images with aligning heights:

[5.5 with height:auto]

https://i.imgur.com/pnIC0kE.jpg

So what would be the solution to restore that behavior?

You'll have to go in an update them with CSS classes to recreate the original behaviour.

#22 @azaozz
2 weeks ago

  • Keywords close 2nd-opinion added

It appears that some images added with the gutenberg editor (no updates since June) now have height and width attributes...

Right. This has been considered "best practice" for very long time, perhaps since the late 1990's - early 2000's. The reason is simple: with width and height attributes the browser will "know" the size of an image before the image file is downloaded. This prevents a (quite unsightly) shifting of the content especially on slower connections.

How that works (in simple terms): Having width and height in the img tag allows the browser to set the intrinsic size of the image as soon as the HTML is downloaded, long before images are downloaded. If not set, the browser has to wait until the image is downloaded.

In WordPress, the old (classic) editor always included width and height for img tags. In the early days of Gutenberg that was dropped for some reason (I'm pretty sure there was/is an old PR to always add width and height to all img tags, unfortunately it was never merged). Currently images in the image block do not have width and height attributes when they are inserted, but get them when they are resized by the user.

In that terms the defects (skewed images on the front-end) described here can be considered "bugs" in the theme. Before WP 5.5 some img tags had width and height, others did not. This was corrected in WP 5.5 and now all img tags (for local images) get width and height added, to comply with the best practices and enhance the website visitors experience. Themes that do not handle img tags with width and height attributes were "buggy" before WP 5.5 too, although that was less noticeable as authors do not resize images in the editor often.

Looking at the (proposed) fixes here: It may make sense to add

img {
  max-width: 100%;
  height: auto;
}

to the default CSS for the front-end (to "help" themes that do not handle images well), however different themes may want to handle this differently, and this may affect how they work. Adding "second-opinion" keyword for that reason.

Last edited 2 weeks ago by azaozz (previous) (diff)

#23 @palfizsolt
2 weeks ago

#51294 was marked as a duplicate.

#24 @palfizsolt
2 weeks ago

#51294 was marked as a duplicate.

Note: See TracTickets for help on using tickets.