Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add width and height attributes to <img> elements #6652

Open
mor10 opened this issue May 9, 2018 · 8 comments

Comments

Projects
None yet
9 participants
@mor10
Copy link
Contributor

commented May 9, 2018

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

This comment has been minimized.

Copy link

commented May 9, 2018

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.

@danielbachhuber danielbachhuber added this to the Merge Proposal: Media milestone May 17, 2018

@ellatrix

This comment has been minimized.

Copy link
Member

commented May 27, 2018

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 comment has been minimized.

Copy link
Contributor

commented Jun 22, 2018

This seems tricky to enforce and maintain going forwards.

@mor10

This comment has been minimized.

Copy link
Contributor Author

commented Jun 22, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2018

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

This comment has been minimized.

Copy link

commented Aug 17, 2018

@matthewmcvickar

This comment has been minimized.

Copy link

commented Dec 21, 2018

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.

(E.g.: Detecting when a sticky-positioned element has reached the bottom of its container requires comparing the height of the container with the scroll position of the sticky element. If the height of the container changes as images load, the relative position of the sticky element would be incorrect unless it is continuously recalculated, which is bad for performance and can jittery.)

@Levdbas

This comment has been minimized.

Copy link

commented May 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.