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

[ProgressEvents] 'loadend' progressevent (Was: Re: [ProgressEvents])

From: Erik Dahlström <ed@opera.com>
Date: Mon, 08 Sep 2008 11:15:19 +0200
To: "Garrett Smith" <dhtmlkitchen@gmail.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, "Charles McCathieNevile" <chaals@opera.com>, public-svg-wg@w3.org
Message-ID: <op.ug5nztidgqiacl@gnorps.linkoping.osa>

On Mon, 08 Sep 2008 03:13:55 +0200, Garrett Smith <dhtmlkitchen@gmail.com> 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.

I see what you mean. Actually on second reading of the SVGT12 spec it doesn't seem to give any constraints on the order in which these events are dispatched, which of course means that authors can't depend on any particular order.

> Please see also:
> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0537.html

Thanks for the pointer.

/Erik, (this is still ACTION-2159)

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 8 September 2008 09:16:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC