- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 12 Jul 2013 19:12:58 +0000 (UTC)
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 July 2013 19:13:22 UTC