- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Mon, 22 Jul 2013 15:37:38 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>
On 12 July 2013 20:12, Ian Hickson <ian@hixie.ch> wrote: > 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 >> ... >> Unless I'm reading it wrong, that suggests >> http://jsbin.com/ifihex/1/edit should 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? It still looks wrong to me. 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) Step 1: img set to unavailable state Step 2: not applicable, no current fetch happening Step 3: not applicable, no current image data Step 4: not applicable, images are enabled & supported Step 5: selected source becomes "/" Step 6: last selected source becomes "/" Step 7: selected source becomes "http://jsbin.com/" Step 8: key set to tuple Step 9: not applicable, key not in list of available images, it's the only image on the page Step 10: await stable state Step 11: not applicable, no further images are added Step 12: not applicable, selected source is "http://jsbin.com/" not null Step 13: fire loadstart on img Step 14: * delay document load event until image fetch completes * fetching image * set image to partially available * I don't know if progress events are fired here or not, given the invalid image data * image fetched * 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 * unable to determine image's width or height due to invalid data, so we fall to the "Otherwise" section (the one with the \21AA before it) * set img to broken state * fire load * fire loadend * resource isn't multipart/x-mixed-replace, so skipping that bit * "Otherwise, either the image data is corrupted in some fatal way" what's this an "otherwise" to, should these steps be followed? If so… * image dimensions cannot be determined, so set img element to the broken state (it already is) * fire error * fire loadend (for a second time) So the order of events is load, loadend, error, loadend. I guess I'm reading it wrong but unsure where. >> "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.) Hah, yeah, that bit was a bit of an afterthought, maybe best for another thread. 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. Jake.
Received on Monday, 22 July 2013 14:38:08 UTC