Need loadstart event on <picture> src change

When using with multiple sources, I’m changing images based on viewport width. However, because CSS kicks in straight away, and the image doesn’t until it has loaded, I’m left with a smaller image blown up too big, or the bigger image scaled down too small. Especially an issue when this occurs during orientation change on devices.

Would be great to have the loadstart event implemented for when the source changes on an image, or something like change event. Then you can trigger different CSS to hide the image while it’s loading in. If cached, then instant and not really an issue.

As discussed with @yoavweiss https://twitter.com/Lletnek/status/626102004251758592

I support this, Tom and I were trying to work out a way to hide the image when it changes and could only come up with very unclean hacky attempts. It is surely a very common use case, essentially lazy-loading for responsive images.

Makes good sense to me. The best way to get this underway would be to submit a PR against our Use Cases and Requirements document repo—that gives everybody a place for continued discussion and a convenient “make this a formal use case” button.

That work for everyone?

With my RICG hat on: what @Wilto said

With my WICG hat on: please join the RICG and sign the CLA before contributing

And with my Blink contributor hat on: I don’t think it would be extremely hard to add this, but we need to create a solid case for it.

@marcosc - opinions from Mozilla are welcome

Cheers all, good stuff! Just submitted PR. Hope that’s alright

Also joined RICG and signed CLA!

While we’re talking about image-based elements and loading events, what’s the deal with the load event on <img>? It’s totally sporadic and unreliable (at least in Chrome), and I can’t find anything on the Web that explains why it’s like that (apart from saying it’s sporadic and unreliable). It seems like it’s definitely in need of a new and/or revamped spec.

@stuartpb sporadic and unreliable in what way? Please open an issue with a test case demonstrating the problems you see.

It’s a cross-browser issue, some of which is inherent to the spec (and some which is solved by yet-unimplemented spec behaviors): if the image is presented from the cache, the load event might fire, or might not fire (I guess the “might” is for when the browser presents a cached version and then replaces it with a new response?). The only thing you can do is check the complete property of the element when the page loads, treat the image as if it’s ready if it’s true, and then just debounce or re-evaluate the image if the load event fires and the image was already completed.

What this model is missing is something like a done event that fires if and when the browser decides that the load event will not fire for the image (specifically, if it got a response like a 304 when requesting the image).

There appears to be some discussion about extending <img> with Progress events, akin to XHR, but the spec for the <img> element doesn’t really seem to match the behavior I’m observing (particularly the tendency for the image to be complete but still fire load).

Actually, the load event not firing if the image comes from the cache isn’t part of the spec, now that I look at it, so I probably should look at the bugs in Blink.

A set of tests cases to explain the behavior you run into would be ideal

Firing loadstart makes sense to me – and in gecko, at least, would be fairly trivial