[chrismorgan]

The failure case is worse than that: I may not have a connection by that time.

Even if I do have a connection and it all succeeds, if the image is not there when I scroll to it, the lazy loader has failed in its job. And that’s pretty much unavoidable in general content—people don’t always scroll smoothly through a page; I may jump down a page at a time, or skim through some headings looking at illustrations that haven’t loaded yet because they only figured I might be interested in them a bit under half a second ago, and latency is half a second plus probably another couple of tenths of a second of annoying fade-in transition. The possibilities are endless.

Come live in Australia for a bit and deliberately use sites from the US with scroll-based lazy-loading: I predict you will rapidly acquire a healthy dislike for the technique! :-)

[stereobooster]

I'll definitely take your use case into the consideration in the future

[chrismorgan]

By handling failure nicely, your component seems to be better than any others I’ve heard of. (Thanks for doing that.) It’s even improving over browsers’ handling of it (right click, reload image) in situations where the intrinsic width and height of the image are not specified or overridden in CSS, which causes the <img> to collapse to generally the alt text height. (Responsiveness is often obtained with images via { max-width: 100%; height: auto }, but browsers don’t use the intrinsic width and height of the image to calculate the auto height. Hmm, I think this could be considered a bug; I might try my luck filing it against Gecko.)

But still, as a user I would consistently prefer a plain <img> to any fanciness.