W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

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

From: Jake Archibald <jaffathecake@gmail.com>
Date: Fri, 5 Apr 2013 11:30:27 +0100
Message-ID: <CAJ5xic_1LJES_oEk5HZ3hQgDJd5dVqs_mxFk3xT9c1XO-ijE_Q@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC