W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [ProgressEvents]

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 8 Sep 2008 19:30:33 -0700
Message-ID: <c9e12660809081930h61b61f86odb2d7a8672fa8a8b@mail.gmail.com>
To: olli@pettay.fi
Cc: "Jonas Sicking" <jonas@sicking.cc>, "Erik Dahlström" <ed@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "Charles McCathieNevile" <chaals@opera.com>, public-svg-wg@w3.org

On Mon, Sep 8, 2008 at 1:01 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> Jonas Sicking wrote:
>> Garrett Smith wrote:
>>> On Sun, Sep 7, 2008 at 8:47 AM, Erik Dahlström <ed@opera.com> wrote:
>>>> Hello webapps wg,
>>>> On behalf of the SVG WG I'd like to propose adding to the ProgressEvents
>>>> spec[1] an event equivalent to the 'loadend' (previously known as
>>>> 'SVGPostLoad') event currently defined in SVG Tiny 1.2 [2].
>>>> The 'loadend' event is dispatched by completion of a load, no matter if
>>>> it was successful or not. In terms of the ProgressEvents spec the 'loadend'
>>>> event would be dispatched following either of 'abort', 'load' or 'error',
>>>> and there must be exactly one 'loadend' event dispatched. In the Event
>>>> definitions table it would look like this:
>>>> Name: loadend
>>>> Description: The operation completed
>>>> How often?: once
>>>> When?: Must be dispatched last
>>> If the event were dispatched last, and there was a progress bar, plus
>>> an overlay, then the success handler would fire before the progress
>>> bar + overlay were hidden/removed.
>>> Please see also:
>>> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0537.html
>> I would be in support of adding such an event. And I agree with Garrett
>> that it makes more sense to dispatch it before the load/abort/error event is
>> dispatched. In fact, we could even make the default behavior of the loadend
>> event be dispatching one of the above three, thus allowing them to be
>> canceled by calling .preventDefault on the loadend event.
>> Would be interested to hear Ollis feedback given that he recently
>> implemented progress events for XHR in firefox.
>> / Jonas
> Sounds good to me, though I don't have strong opinion whether
> load/abort/error should be the default behavior for loadend. Maybe it is
> better to not to add any default behaviors to PE.
> The new event should be added to XHR2 too.
> One thing to be clarified is that what should happen if loadend handler
> restarts XHR - should load/abort/error still fire?

Are you asking: What if the loadend handler calls open() on the same
connection in loadend?

When loadend is called, the actual completion event ("abort" | "fail"
| "load" ) has not fired.

Calling open should cause the previous connection to end. Jonas
suggested that the corresponding event ("abort" | "fail" | "load")
should then fire unless e.preventDefault() is called.

Just curious: Why call open() again in loadend?

I do not see a sequence of events for SVG:

However, I noticed this example:-

function imageLoadStart (evt) {
  progressBar.setFloatTrait("width", 0);
  var loadingAnimation = document.getElementById('loadingAnimation');

- attempts to reference progressBar without first declaring it. The
example also makes use of an 'ev' namespace that I can't see being


A working example would be great.


> -Olli
Received on Tuesday, 9 September 2008 02:42:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:21 UTC