- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Thu, 23 Oct 2008 19:57:55 -0700
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Web Applications Working Group WG" <public-webapps@w3.org>
On Thu, Oct 23, 2008 at 6:38 AM, Jonas Sicking <jonas@sicking.cc> wrote: > > Garrett Smith wrote: >> >> On Tue, Oct 21, 2008 at 5:32 PM, Garrett Smith <dhtmlkitchen@gmail.com> >> wrote: >>> >>> On Tue, Oct 21, 2008 at 3:27 AM, Charles McCathieNevile >>> <chaals@opera.com> wrote: >>>> >>>> >>>> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24 >>>> >>>> Hopefully this draft is ready for last call. So please have a look >>>> through >>> >>> It was agreed that loadend should fire prior to abort | error | load. > > I do remember that we talked about it that way, and also talked about having > the default action of the loadend event be to fire the appropriate > abort/error/load event. > > However I'm not sure why that way is better? I.e. why would you want to > prevent abort/error/load from firing? > I can't imagine why anyone would would do that. Seems like a red herring. The goal is to know when a request has completed, to remove the "loading state indicator" (e.g. progress bar, busy icon, overlay). That is loadend's raison d'être, as I see it, and that is the exact reason I proposed this to "Chaals" over a year ago (it is in the archives). If loadend fires after "load | abort | error", the "loading state indicator" would be removed after that. I think that is less desirable. We could have it one of two ways: Garrett's way: "I'm done" then "here's your data." Chaals' way: "here's your data" then "I'm done." Garrett > > / Jonas > >
Received on Friday, 24 October 2008 02:58:31 UTC