On Thu, Jan 3, 2013 at 9:57 PM, Ian Hickson i...@hixie.ch wrote:
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
On Thu, Jan 3, 2013 at 6:49 PM, Ian Hickson i...@hixie.ch wrote:
As an aside, it's odd that if images are unsupported or disabled, no
event is fired at all (update the image data, step 4). That means
that if you do this:
var url = URL.createObjectURL(blob);
img.src = url;
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
On 2/23/12 5:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/23/12 7:38 PM, Hans Muller wrote:
Hans - It's useful if you want your listener to run after all of the
load listeners have run, and code that you haven't written adds its own
load listeners.
I strongly urge you to read
On 2/24/12 12:36 PM, Hans Muller wrote:
Good point, although this approach seems to lead to the very same dystopia
you
were just warning about. If everyone tries to schedule their image
listener last
with setTimeout()...
Sure. There's no way to fix that problem technologically. Just saying
It seems odd that loadend is considered useful enough to be recommended by
Progress Events, but not useful enough to be used here.
As an aside, it's odd that if images are unsupported or disabled, no event
is fired at all (update the image data, step 4). That means that if you
do this:
var url
Ian Hickson and I have been debating the merits of adding support for the
loadend event to images on https://bugs.webkit.org/show_bug.cgi?id=76102.
Dirk Schulze requested that the discussion be relocated here, since it's
about a feature and not the details of an implementation change.
Here's a
On 2/23/12 7:38 PM, Hans Muller wrote:
Hans - It's useful if you want your listener to run after all of the
load listeners have run, and code that you haven't written adds its own
load listeners.
I strongly urge you to read
http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx
On Thu, Jan 12, 2012 at 4:19 PM, Hans Muller hmul...@adobe.com wrote:
A group of us at Adobe has been looking into adding support for
ProgressEvents to images. The overall goal is to simplify image download
progress reporting by supporting roughly the same progress events as XHR and
the
Thanks for the encouraging words.
For cross-site images for which crossOrigin is not set, we'd proposed
normalizing the loaded and size ProgressEvent attributes:
https://bugs.webkit.org/show_bug.cgi?id=76102
ProgressEvents for cross-origin images should not reveal the actual
resource size per
On Mon, Jan 23, 2012 at 8:44 AM, Hans Muller hmul...@adobe.com wrote:
Thanks for the encouraging words.
For cross-site images for which crossOrigin is not set, we'd proposed
normalizing the loaded and size ProgressEvent attributes:
https://bugs.webkit.org/show_bug.cgi?id=76102
A group of us at Adobe has been looking into adding support for ProgressEvents
to images. The overall goal is to simplify image download progress reporting
by supporting roughly the same progress events as XHR and the File API for
image elements. For example one could connect an image to a
I've wanted this before. It would be useful for more granular loading
progress indicators for eg. WebGL apps, for example, and anything else that
loads images without displaying them as they load.
On Jan 12, 2012 4:20 PM, Hans Muller hmul...@adobe.com wrote:
A group of us at Adobe has been
13 matches
Mail list logo
