Bug 180580 – Feature request: Improve image loading (height) on slow connections

• Component: Images
• Status: RESOLVED DUPLICATE

[Craig Francis]

Created attachment 328806 [details]
Loading image on a slow connection

To avoid reflow while the page is loading (e.g. on a slow connection), we could improve how the image size is calculated.

At the moment websites can provide the width/height of the image in the HTML.

But websites will typically override the width in CSS to a percentage value, while using `height: auto` (so the aspect ratio is maintained).

When this happens, the height of the image is assumed to be 0px, which is nearly always wrong. It's not until the image is downloaded does the correct height get calculated.

Could we instead take the width/height (as set in the HTML) and use that to calculate the height while the page is loading.

---

I've attached a video to show what happens at the moment.

[Craig Francis]

Also requested on Chrome and Firefox:

https://crbug.com/732794
https://bugzilla.mozilla.org/show_bug.cgi?id=1424247

[Craig Francis]

Suggestion from fantasai on the Firefox issue log...

Assuming the CSS `aspect-ratio` property is added, that would be a perfect way to introduce this:

https://github.com/WICG/aspect-ratio

When the width/height attributes from the <img> are copied into the CSS properties, the browser could also set a default `aspect-ratio`. So that when the websites CSS is processed (and replaces the width/height), the aspect-ratio will still be available for any missing values (e.g. height: auto).

[Eric Portis]

Consensus on using width/height to establish <img> aspect ratio before the resource has loaded was achieved here: https://github.com/WICG/intrinsicsize-attribute/issues/16

Firefox shipped this today in v71 and has been doing some significant developer outreach/education about it: https://twitter.com/jensimmons/status/1201950419334897664

Chrome will ship this in M79, on Dec 9th: https://chromestatus.com/feature/5695266130755584

Web platform tests are here: https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.html?label=master&label=experimental&aligned&q=aspect-ratio

Bring this feature to WebKit!

[Maciej Stachowiak]

`aspect-ratio` is prefixed in WebKit, not sure if this is due to non-compliance in some way or just lag.

Other than that, all this requires (it seems) is adding this to html.css:

img, video {
    aspect-ratio: attr(width) / attr(height);
} 

(Well, that and test cases).

Also seems like this solution might be insufficient for `<picture>`, where often the different sources will have different aspect ratios.

[Eric Portis]

Great!

> (Well, that and test cases).

Test cases beyond the web platform tests? https://github.com/web-platform-tests/wpt/blob/master/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.html

> Also seems like this solution might be insufficient for `<picture>`, where often the different sources will have different aspect ratios.

Yes! There's some good discussion on what to do about that in the original thread: https://github.com/WICG/intrinsicsize-attribute/issues/16, which has since moved to this issue: https://github.com/whatwg/html/issues/4961

TL;DR maybe we can send `height` and `width` from the `<source>` to the `<img>`, along with the `src`? Comments are still being gathered and it hasn't been spec'd anywhere yet.

[Eric Portis]

One possible problem with the UA rule...

If the actual aspect ratio of the resource differs from `attr(width) / attr(height)`, Both Chrome and Firefox will NOT distort the image; they discard the `height`/`width` ratio, and use the image's actual, intrinsic ratio.

The proposed UA rule would do the opposite, I think?

[Eric Portis]

Looks like this can be marked as a duplicate of https://bugs.webkit.org/show_bug.cgi?id=201641, where this is being actively worked on

[Simon Fraser (smfr)]

*** This bug has been marked as a duplicate of bug 201641 ***