- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Fri, 5 Apr 2013 11:30:27 +0100
- To: WHATWG <whatwg@whatwg.org>
Been reading the steps for image downloading - http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data As far as I can tell: Step 12 "If selected source is null" is the only step where an "error" event can be fired and abort before step 14. Step 14 always results in firing a "load" event, either because the image "download was successful and the user agent was able to determine the image's width and height", or "Otherwise". Then if "either the image data is corrupted in some fatal way such that the image dimensions cannot be obtained, or the image data is not in a supported file format" an "error" event is fired. Unless I'm reading it wrong, that suggests http://jsbin.com/ifihex/1/editshould fire a "load" then an "error", which doesn't feel right. I don't think the "Otherwise" step should fire "load", just "loadend". Related: "load" is fired once the width & height can be determined, which suggests that an un-decodable image, but with intact headers (which give the width & height) will fire "load" but not "error". I agree with this, as it means the browser can defer decoding to render time, but do we need a way in JS to confirm an image is decodable? Cheers, Jake.
Received on Friday, 5 April 2013 10:30:59 UTC