This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html Multipage: http://www.whatwg.org/C#img-load Complete: http://www.whatwg.org/c#img-load Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Comment: error/loadend are always simple events "first fire a simple event named error at the img element and then fire a simple event named loadend at the img element." Why not use progress events for error/loadend here in the same-origin case? Posted from: 210.95.255.149 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 OPR/21.0.1432.48 (Edition Next)
What would it mean for them to be progress events?
They would use ProgressEvent instead of just Event. In XHR they use ProgressEvent. <img> seems to switch between ProgressEvent and Event depending on origin, except error/loadend which are always Event. I think they would expose the same information as the last "progress" event.
Do "error" and "loadend" normally expose the last "progress" event's information? If they do normally do that, then sure...
Thinking about this some more, it seems simpler and possibly safer to always use Event for error, and not fire 'progress' at all until dimensions are known (it would be confusing anyway to fire 'progress' events for two ongoing fetches in the parallel loading case).
Fire 'progress' event only for the current request. https://github.com/ResponsiveImagesCG/picture-element/commit/22efd4478d7714ac12fd128ca2c455d0f91f42a4