On Fri, 5 Apr 2013, Jake Archibald wrote: > > 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".
This has either been fixed already, or I don't understand the problem. Can you look at the spec again and see if it's ok now? > 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". Right. > 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? What's the use case? (Surely the server should check this on the server.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'