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

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

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 12 Sep 2013 00:24:24 +0000 (UTC)
To: Jake Archibald <jaffathecake@gmail.com>
Message-ID: <alpine.DEB.2.00.1309112252030.12199@ps20323.dreamhostps.com>
Cc: WHATWG <whatwg@whatwg.org>
On Mon, 22 Jul 2013, Jake Archibald wrote:
> 
> Take http://jsbin.com/ifihex/1/edit - the image on this page receives a 
> valid & full HTTP request, but the received data isn't valid image data 
> (it's html).
> 
> Starting from 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data, 
> here's how I see the image loading according to the spec
> 
> (everything seems fine until step 14)
> [...]
> * this is the point where I start to get lost, I'm not sure which
> else-like statements (as in "On the other hand" and "Otherwise") are
> linked to which if-like statements

Oh, yeah, this is very confusing. My bad.

I've tried to fix it. Let me know how it is 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.)
> 
> The use-case would be image loading that happened without a server. Eg, 
> an in-browser Photoshop that operated without user interaction. User 
> selects file on their machine, it has correct headers so fires a load 
> event, but cannot be painted onto the canvas (or paints incorrectly) due 
> to corrupt data. The in-browser app is unable to detect the image is 
> corrupt without building a decoder/validator in JS.

Well... there is one way to tell right now. You can try to draw it to a 
<canvas> and see if anything got drawn by examining all the pixels; if no 
pixels got drown, then it has some data integrity issues.

But really if you're implementing a Photoshop equivalent, you really 
_should_ implement your own decoder, so you can do things like EXIF 
manipulation, handle other image formats, do "pngcrush"-like work, etc.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 September 2013 00:24:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:09 UTC