[whatwg] img loading events - can load & error fire for the same image?
ian at hixie.ch
Fri Jul 12 12:12:58 PDT 2013
On Fri, 5 Apr 2013, Jake Archibald wrote:
> Been reading the steps for image downloading -
> 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?
> "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?
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg