Bug 76102 – Add support for loadstart, progress, and loadend ProgressEvents to the IMG tag.

• Status: NEW
• Component: Images

[Hans Muller]

Many applications that display large images, large numbers of images, or images that load slowly, would benefit from support for progress events. Displaying a progress indicator for work being done on the user's behalf is reassuring.  Support for progress events would make it straightforward for applications to do this when images are being loaded.

Currently some applications use XMLHttpRequest (XHR) to download image data while reporting progress. Doing so is somewhat complicated and can be inefficient.

This is a request to add support for loadstart, progress, and loadend events to the IMG tag. The semantics of the events would be roughly the same as for XHR or the File API. ProgressEvents would be dispatched for loadstart, progress, abort, error, load, and loadend. 

We suggest promoting the type of the existing IMG load, error, and abort events from Event to ProgressEvent.

ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations.  This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images.   Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes.  A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress.  Normalization would set total to a constant like 1000, and loaded to a relatively correct value.

[Ian 'Hixie' Hickson]

I'd recommend not sending any events at all for non-CORS-aware cross-domain images.

[Hans Muller]

(In reply to comment #1)
> I'd recommend not sending any events at all for non-CORS-aware cross-domain images.

I assume that you don't mean that we should no longer dispatch the existing load/error/abort events for non-CORS-aware cross-domain images?   And if we're going to carry on dispatching those events, dispatching the companion loadend event wouldn't expose any new information.

[Ian 'Hixie' Hickson]

I would only fire 'load' and 'error'.

I would avoid firing the other events because it either exposes information, in which case it's a security problem, or it exposes no information, in which case it's a useless API that will mislead authors.

[Hans Muller]

(In reply to comment #3)
> I would only fire 'load' and 'error'.
> 
> I would avoid firing the other events because it either exposes information, in which case it's a security problem, or it exposes no information, in which case it's a useless API that will mislead authors.

The loadend event, which is what I assume you're characterizing as "useless", enables doing work after either the load or error listeners have run.   That seems useful on the face of it, and I assume that's why the ProgressEvent spec includes loadend.

[Ian 'Hixie' Hickson]

"loadend" is basically uninteresting. It's just a shortcut to calling the same function from both the 'load' and 'error' handlers. It literally saves only a few characters:

   img.onloadend = function () { };

...vs:

   img.onload = img.onerror = function () { };

[Hans Muller]

(In reply to comment #5)
If only one image error/load listener is used and you're defining it yourself then I agree that  there's definitely not much value in having a loadend event.  If other code contributes image listeners, then there is value.  For example:

function notMyShowImageFunction(image, url)
{
    image.onload = doSomethingAtLoadTime;
    image.src = url;
}

image.onloadend = doThisAfterAllLoadListenersHaveRun;
notMyShowImageFunction(image, "...");

[Ian 'Hixie' Hickson]

That seems like a rather obscure edge case, and you can work around it using setTimeout() (in the load/error event handler) anyway.

[Dirk Schulze]

(In reply to comment #7)
> That seems like a rather obscure edge case, and you can work around it using setTimeout() (in the load/error event handler) anyway.

Wouldn't it be better to move this discussion to #whatwg mailing list? I'd like to use bug reports for discussions about implementation details and not for general discussions about features.

[Ian 'Hixie' Hickson]

Spec updated.

[Rudin]

Any news on this?
Image progress events were added to the HTML spec:
http://www.whatwg.org/specs/web-apps/current-work/#the-img-element

Want this, need this. Been able to do this in Flash like, back in '99.. ;-(

[Yonatan]

Does anyone know if this bug is scheduled to be fixed soon?

[Martin P.]

+1.

I'd like to see that implemented too.

It will especially by useful for the new <picture> tag and the srcset-attribute for <img> to know when another resource (eg. on orientation change) is being loaded...

[Simon Pieters (:zcorpan)]

(In reply to comment #12)
> +1.
> 
> I'd like to see that implemented too.
> 
> It will especially by useful for the new <picture> tag and the
> srcset-attribute for <img> to know when another resource (eg. on orientation
> change) is being loaded...

That is not part of the spec currently. What's the use case? (Please file a new spec bug https://github.com/ResponsiveImagesCG/picture-element/issues )

[Martin P.]

(In reply to comment #13)
> (In reply to comment #12)
> > +1.
> > 
> > I'd like to see that implemented too.
> > 
> > It will especially by useful for the new <picture> tag and the
> > srcset-attribute for <img> to know when another resource (eg. on orientation
> > change) is being loaded...
> 
> That is not part of the spec currently. What's the use case? (Please file a
> new spec bug https://github.com/ResponsiveImagesCG/picture-element/issues )

Yes it is part of the WHATWG HTML Living Standard specs. Search for "loadstart" in http://www.whatwg.org/specs/web-apps/current-work/#the-img-element.

I think there is no other way of detecting that a (specific) image starts being loaded by the browser. That can be useful for displaying loading indications.

I find it especially interesting when using the <picture> element. By using <picture>, the src of an <img> tag can change after the page finished loading, eg. on a viewport resize or an orientation change. That results in a blank/white image for the time the images is actually being loaded - with a loadstart event you could let the user know about the loading, eg. by showing a loading indicator.

[Simon Pieters (:zcorpan)]

(In reply to comment #14)
> Yes it is part of the WHATWG HTML Living Standard specs. Search for
> "loadstart" in
> http://www.whatwg.org/specs/web-apps/current-work/#the-img-element.

That algorithm is not run "eg. on orientation change". Then this algorithm is run instead https://html.spec.whatwg.org/multipage/embedded-content.html#img-environment-changes and it does not fire loadstart/progress.

> I think there is no other way of detecting that a (specific) image starts
> being loaded by the browser. That can be useful for displaying loading
> indications.

Why would you want a loading indicator for environment changes instead of just swapping the image when it is loaded?

> I find it especially interesting when using the <picture> element. By using
> <picture>, the src of an <img> tag can change after the page finished
> loading, eg. on a viewport resize or an orientation change. That results in
> a blank/white image for the time the images is actually being loaded - with
> a loadstart event you could let the user know about the loading, eg. by
> showing a loading indicator.

No, the old image would keep showing until the new one is completely loaded, per spec.