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

Re: [whatwg] ProgressEvents for Images

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 4 Jan 2013 03:57:50 +0000 (UTC)
To: Glenn Maynard <glenn@zewt.org>
Message-ID: <Pine.LNX.4.64.1301040355130.12992@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org
On Thu, 3 Jan 2013, Glenn Maynard wrote:
>
> It might make sense to fire onerror if the image doesn't get loaded 
> because images are disabled.  Guaranteeing (or coming closer to 
> guaranteeing, at least) that onload or onerror will always be fired 
> would reduce the differences in event flow when images are disabled.

When images are disabled, the image will typically be loaded when the user 
requests that they be loaded, which is when onload should fire. I think 
it'd be really confusing to have fired onerror first.


> The particular case above should be fixed, at least in the most common 
> cases, by auto-revoking blobs, since you'll no longer need to carefully 
> call revokeObjectURL.  (I've come to the conclusion that 
> URL.revokeObjectURL was a very badly flawed idea, since it introduces 
> manual resource management in a platform not designed for it.)

I'm not exactly clear on what exact words are needed here. If you could 
file a bug cc'ing the relevant people with a description of how to make 
this work, that'd be great. (I don't think this should be special-cased 
for <img>; there are dozens of other places in the spec where a URL may or 
may not be fetched for various reasons.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 4 January 2013 03:58:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT