<CA+c2ei8gVECcSPtaQqkHr5ebWnDeUmXjoO2VWsdvtP2Q7Fr=uA@mail.gmail.com>
Current votes: None.
On Thu, Jan 12, 2012 at 4:19 PM, Hans Muller <hmuller@adobe.com> wrote: > A group of us at Adobe has been looking into adding support for ProgressE= vents to images. =A0The overall goal is to simplify image download progress= reporting by supporting roughly the same progress events as XHR and the Fi= le API for image elements. =A0 For example one could connect an image to a = progress element like this: > > <img id=3D"image" src=3D"sample.jpg" > =A0 =A0onloadstart=3D"showProgressBar()" > =A0 =A0onprogress=3D"updateProgressBar(event)" > =A0 =A0onloadend=3D"hideProgressBar()"/> > > Developers have taken various tacks to enable progress reporting, for exa= mple in some cases XHR can be used to download image files. =A0Max Vujovic = just published a blog about the practicalities of doing so: http://blogs.ad= obe.com/openweb/2012/01/13/html5-image-progress-events/. =A0We think it wou= ld be preferable to provide support for image progress events directly. > > We're working on a prototype implementation for WebKit and have filed a b= ug that explains what we're up to in a little more detail: https://bugs.web= kit.org/show_bug.cgi?id=3D76102). > > It's probably worth pointing out that the beforeload event, which is curr= ently under discussion, addresses a different use case. =A0Our proposal is = intended to enable applications to give the user feedback about image downl= oad progress, it's not intended to enable security or efficiency by preempt= ively blocking or transforming image downloads. > > We'd appreciate feedback on this proposal. For cross-site images this would leak the compressed size in bytes of the loaded image (except when the crossorigin attribute is set). This would very unfortunately in many cases leak sensitive information. But if we restrict these events to only fire for same-origin loads, as well as loads where the crossorigin attribute is in effect, then this sounds like an awesome idea. / Jonas