That's kind of the browser's responsibility, really. The image element already covers what is required to instruct the user agent that there a) is an image resource and b) what its location is. It's then up to the browser to do the right thing with that data. It's nice that people are finding ways to preempt that in case the browser they're in is dumb as dirt, but it's really not the role of the spec to tell user agents how to deal with loads of images. If I'm browsing my gigabit intranet image repositories on any of our workstations, I don't want my user agent to be "intelligent" and just load everything, because it can. If I'm on LTE mobile, I want my browser to be a little smarter about swapping in/out image content. If I'm on 3G, I don't want the browser to load any images at all unless I tell it to. But those are my wants, those are not things the spec should "ordain" user agents must (in the spec definition of must) do.

React components like these are nice, but the real question is why doesn't your _browser_ already do this. Not "why doesn't the spec say what needs to happen", but why haven't Microsoft, Google, Mozilla, Opera, etc. implemented network-and-content-traversal-appropriate image handling? (one answer might be "because apparently users don't actually ask for it enough", but I honestly don't know).

Because there’s no way to standardize the behavior across user agents to the extent necessary that developers could actually rely on it producing a consistent experience across a large user-base.

Conversely, there is also no way to standardize which solution to use to the extent necessary that developers could actually rely on it producing a consistent experience across a large user-base.

You don't need standard behaviour, you just need _good_ behaviour. And if every browser does that differently, but it's appropriate to the network speed and processing capabilities, then as a dev the issue of "making sure images load appropriately" becomes as irrelevant as "making sure your webfont actually loads" has become in the modern browser landscape.

Downloading all the images provides a good user experience. If your intranet has a GB of images on a single page, that's on you - even if browsers did as you suggest, any older browser would still saturate your network link.

These fancy image placeholders seem more designed to save on CDN costs than to provide a good UX.

I think you misread what I said as "I want the browser to load all the images, all the time" instead of "I want the browser to download and render in ways that are appropriate to the constraints of the network and processing power, not have to rely on a million folks each inventing their own lazy-loader".

I think this is a typical lifecycle. The community will be a magnificent shim or two, then the committees will wait and see if it's a winner, then start adopting the key elements. That's why nearly all of jQuery is now supported natively by browsers and why we have <video> tags instead of flash.

Read this https://github.com/whatwg/html/issues/2806

Read the whole thing. As is typical with committees, they harp on about crap that doesn’t matter to 99% of users, and thus any viable solution gets delayed indefinitely. So I guess we get shitty image loading across the whole web, oh well.

Perfect opportunity for a reusable web component that anyone could consume