Add width and height attributes to <img> elements

[mor10]

Issue Overview

height and width attributes have been removed from the generated markup on images. I believe I advocated for this at some point, and per HTML5 it is allowable and technically correct. However, unsized media, combined with techniques such as lazy-loading, can cause an uncomfortable user experience because the contents surrounding the image will appear to "jump around" while the image loads.

For this reason, Google is now pushing for explicit image sizing in HTML to be a best-practice, theoretically enforced by a feature-policy. They are doing this as part of a new standards proposal through the Web Incubator Community Group. Quoting from the proposal:

"Layout instability is one of the existing problems that are aggravating web experiences. For example, when the size of an element is unspecified, it will cause the content around the element to jump around. This is because the renderer does not know how much space to reserve for an image until the image is loaded, and once the image size is known the renderer will have to re-layout everything, causing the content to shift on the web page.

Unsized media policy is aiming to fix the problem by requiring all media elements to provide a size; if they don't, a default will be chosen, so that the image doesn't change size after loading."

To protect end-users from the "aggravating web experience" of content jumping around as images are loaded, and to avoid future flags being triggered by the above mentioned feature-policy, I suggest the height and width attributes be added back in for inserted images.

[jsmoriss]

And on a related note, it would be really nice to have the 'wp_get_attachment_image_attributes' filter applied to image attributes as well. :)

#2258

js.

[ellatrix]

How would this work on full width images? Or if we continue with the image resizing as a percentage idea, how would this work together? A display filter that uses the width set by the theme? How will the images be responsive? Does that work together? I think we need some more information here to implement it.

[mtias]

This seems tricky to enforce and maintain going forwards.

[mor10]

I'm talking about the physical size of the image file. WordPress knows this image size as it adds the image. It is not related to the displayed size. The feature is there to tell the browser the proportion between height and width. That's also why it is now added without unit values. So height="400" width="600" etc. Should require zero maintenance and can be handled in core by default.

[joemcgill]

I agree that the default markup for image blocks should include inline width and height attributes as a best practice with performance implications, as Addy briefly describes in his image optimization guide:

Omitting the width or height attributes on an image can also negatively impact performance. Without them, a browser assigns a smaller placeholder region for the image until sufficient bytes have arrived for it to know the correct dimensions. At that point, the document layout must be updated in what can be a costly step called reflow.

For WordPress, these attributes are also taken into account when calculating the sizes attribute for responsive images. Omitting them results in an incorrect sizes attribute, which means we are telling the browser to download an incorrect—and often much larger than necessary—image size.

[lizkarkoski]

Noting an additional report from the forums:
https://wordpress.org/support/topic/width-and-height-of-the-image/#post-10596528

[matthewmcvickar]

I'll note that an important reason for these attributes to exist is for calculating the aspect ratio of the image, as @mor10 mentioned.

This is particularly vital when lazy-loading images, otherwise the browser has no idea the size of the unloaded image, and when it loads, content jumps around. In addition to being annoying to the user, this causes unnecessary DOM reflows and repaints and can throw off any JavaScript that relies on the dimensions or positioning of other elements, requiring repeated recalculation.

[Levdbas]

I completely agree that we need the width/height attributes as well to calculate aspect ratios. Right now this completely breaks the ability to lazyload images.

[hatsumatsu]

Needed for the mentioned reasons! Just curious, what's blocking a fix?

[pattonwebz]

I just stumbled across this issue due to a conversation on Twitter started by Jen Simmons. I did not realise that images by default did not include height and width when output through Gutenberg blocks. That is an oversight on my part for not noticing before this point but what can I do to help now that will move this forward?

[joemcgill]

Related WICG discussion about updating the best practice to include dimension attributes is here: WICG/intrinsicsize-attribute#16. Brought to my attention by @jensimmons via @mor10.

[samikeijonen]

Is there PR or other movements on this one? Would be super to have this at least first in plugin version.

[hacknug]

Just opened #19790 which addresses the issue although I haven't tested this thoroughly.

EDIT: Just saw #9421 and that probably is better than mine in case anyone wants to review.

[kasparsd]

Here is a filter to add the width and height attributes of the original image (with the original aspect ratio) to all images in the post content:

add_filter( 
	'the_content', 
	function( $content ) {
		if ( false === strpos( $content, '<img' ) ) {
			return $content;
		}

		if ( ! preg_match_all( '/<img\s[^>]+>/', $content, $matches ) ) {
			return $content;
		}

		foreach ( $matches[0] as $image ) {
			if ( false === strpos( $image, 'width=' ) && preg_match( '/wp-image-([0-9]+)/i', $image, $image_class_id ) ) {
				$attachment_id = absint( $image_class_id[1] );
				$src = wp_get_attachment_image_src( $attachment_id, 'full' );

				if ( ! empty( $src[1] ) && ! empty( $src[2] ) ) {
					$image_with_width_height = str_replace(
						'src=',
						sprintf( 'width="%d" height="%d" src=', $src[1], $src[2] ),
						$image
					);

					$content = str_replace( $image, $image_with_width_height, $content );
				}
			}
		}

		return $content;
	} 
);

This is useful because it adds the attributes to all images while the proposed fix in Gutenberg will probably only apply to newly added images.

[paaljoachim]

I shared the link into the core-media channel on Slack. Hopefully we will get a status update on this issue.

[adamsilverstein]

Image width and height are added automatically by core since WordPress 5.5. See https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/.

@joemcgill / @mor10 Can you confirm this is no longer an issue?

[adamsilverstein]

Suggest closing as fixed.

[joemcgill]

@adamsilverstein correct, this is being handled content filtering in WordPress, though the image block itself is still not adding height/width attributes to the markup generated by the block. For now, I think it's ok to resolve this ticket because the current approach allows the dimensions to be more flexible as content width requirements change in the future.

[paaljoachim]

I am closing this issue. It can always be reopened if need be.

[adamsilverstein]

I noticed recently that when inserting an image from a URL we don't set height and width in the HTML. Is that covered in an existing issue or trac ticket somewhere? cc: @joemcgill

[westonruter]

To cite my WordPress/performance#49 (comment):

what if the author is linking to an image without consistent width/height? For example, they could be linking to https://source.unsplash.com/random so that a random image with random dimensions are used. If the dimensions were obtained and stored, then this would break. One may say this authors shouldn't be doing this, but alas, it's something users may indeed do (and have a need to do so).