Garrett Smith wrote:
>>> I do like the symmetry in the current proposal where loadstart is
>>> the first thing that fires, and loadend is the last thing. Seems
>>> very intuitive.
>> I agree that dispatching loadend last makes sense.
>
> Other than "liking the symmetry" can you provide a reason for why it
> "makes sense"?
The symmetry is why I think it makes sense. In general people will have
fewer bugs if things work the way they intuitively expect. The question
is what people intuitively expect.
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.
I thought that that was the setup (with default actions) that we had
discussed. I agree it's not a relevant use case, which in fact is what I
was arguing in my paragraph above.
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).
I agree. Not sure if that is what you want to do before or after getting
the load/error/abort event though?
I should mention that I'm not particularly married to having things one
way or another. But I think we should have reasons for choosing.
/ Jonas
/
