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:
http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#EventsPostload

However, I noticed this example:-

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

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

http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#events__ProgressEvent_total

A working example would be great.

Garrett

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

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT