Summary: | Add support for loadstart, progress, and loadend ProgressEvents to the IMG tag. | ||
---|---|---|---|
Product: | WebKit | Reporter: | Hans Muller <giles_joplin> |
Component: | Images | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Enhancement | CC: | acucu, ap, d-r, efidler, ian, josh, jussi.kukkonen, kennyluck, krit, lmcliste, mihnea, mike, mrtn, rudinswagerman, tonyg, WebkitBugTracker, yonatan, zcorpan |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Description
Hans Muller
2012-01-11 14:14:08 PST
I'd recommend not sending any events at all for non-CORS-aware cross-domain images. (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. 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. (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. "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 () { }; (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, "..."); That seems like a rather obscure edge case, and you can work around it using setTimeout() (in the load/error event handler) anyway. (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. Spec updated. 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.. ;-( Does anyone know if this bug is scheduled to be fixed soon? +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... (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 ) (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. (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. |