Ability to disable images loading, to customise when they load with scripting

[keithamus]

What problem are you trying to solve?

Currently to defer an image from loading, one can use loading=lazy which has generally desirable heuristics, however issues like #10056 demonstrate a need for customisable heuristics for loading an image.

Some use cases demonstrating this need:

• require user activation for sensitive images (eg “click to show this image with a content warning/spoilers”)
• require user activation for images when the user is in bandwidth constrained mode
• providing users with a “hide user generated images” site wide setting, allowing website authored images to load but UGC images won’t.
• deferring images until as late as possible, but sooner than lazy, eg images inside a dialog won’t load until the invoker is hovered/focused/clicked (possible today with loading=lazy but in a sense a bit of an abuse of the feature)

What solutions exist today?

The classic way to do this is to omit src and instead use data-src; then have some scripting to remove effectively rename data-src back to src to trigger loading. This is not a perfect solution though; it has some security implications as it increases the surface area for malicious actors to supply bad urls to be inadvertently loaded by a site.

How would you solve it?

My proposal (subtly different from #10056, but with significant overlap) is to extend the loading attribute to supply a none value. Any <img loading=none src=…> or <iframe loading=none src=…> would not load, prefetch, or resolve dns to the given src. This would allow pages to use scripting to wait for their ideal conditions to alter the loading attribute to another value to another value, which may include being later than what lazy provides (use case: offering a “click to show image” on bandwidth constrained devices, or for images with content warnings).

Anything else?

No response

[hsivonen]

This issue could use a more detailed analysis of the good and bad aspects of both the "classic way" and what's being proposed and why the difference justifies the addition of the proposed mechanism given that the "classic way" exists.

Notably, the fallback behavior in browsers that don't know about the proposed feature seems ill suited for the use cases listed.