[whatwg] img loading events - can load & error fire for the same image?

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'