Re: [whatwg] Progress Events "done" event

Hi all, re-rasing this old mail since it never got an official reply.

The suggestion here is to add a "done" event that could be listened to 
rather than having to listen to all three of "load", "abort" and "error".

I think in many cases you don't really care why a load ends, just that 
it has ended. For example to hide progress bars or throbbers, or to 
start displaying resources on the page (for example google calendar 
doesn't display until some set of resources is done loading).

It does add the overhead of one extra event in the UA, but it does allow 
cleaner code on the part of the web author. It might also encourage 
pages to deal with network errors rather than just failing in the face 
of them.

The main questions around the event, apart from if it's needed, is when 
it should fire (before or after the load/error/abort event), and what 
its name should be ("done", "loadfinish", "loadend").

/ Jonas

Garrett Smith wrote:
> On 9/10/07, Charles McCathieNevile <chaals@opera.com> wrote:
>> Forwarded and reply-to set to webapi-public, which is where you should
>> send things you want actively considered for the W3C progress events spec.
>> That's the group working on the spec.
>>
> I had a mistake. Thank you.
> 
>> I think there is enough detail left in the mail below for webAPI people to
>> get this. The idea is that it might be helpful to add a "done" event that
>> could be trapped instead of having to get the seperate possible events
>> that mean you are done.
>>
> Correct.
> 
>> I'm inclined not to add a "done" event. It invites code repetition in the
>> browser, which is not helpful in the case of mobile browsers.
> Actually, having a "done" event avoids repetition by allowing the
> author to address the completion aspect singularly, thus avoiding
> having to use a loop or copy-pasting code blocks to
> success/failure/abort.
> 
> Also, I
>> think the example doesn't take into account that where the load is
>> aborted, or wherer there is an error, you often want to pass by some
>> relevant function such as explain what happened before calling the code to
>> clean up the progress bar.
>>
> It sounds like you are suggesting a use case that introduces a timing
> sequence. Let me see if I understand you correctly:
> Bad Path (error)
> 1. call fails
> 2. show error msg for a brief period.
> 3. when the error msg hides, hide the progress bar.
> 
> Is this what you mean?
> 
> In that case, a 'done' event would not be suitable.
> 
> However, in the following use case:
> Bad Path (Error)
> 1. call fails.
> 2. remove progress bar and immediately show an error.
> 
> or:
> Bad Path (Error)
> 1. call fails
> 2. replace progress bar with error msg
> 
> 
> If success and abort had similar functionality, the developer could
> add a second callback to each completion event. A 'done' event would
> not be necessary:
> 
> var doneEvents = ["error", "abort", "load"];
> 
> doneEvents.forEach( function( type ) {
>     image.addEventListener( type, hideProgressBar, false );
> });
> 
> function hideProgressBar( progEv ) {
>     document.getElementById("progressBar")
> }
> 
> A done event would allow the developer to add only one eventListener
> to remove the progress bar when the event was done.
> 
> If used properly, it would be used to avoid repetition (concise,
> explicit). For example:
> image.addEventListener( "done", hideProgressBar, false );
> 
> It would be a VERY BAD use of a done event:
> 
> image.addEventListener( "done", checkCallDone, false );
> function checkCallDone( progEv ) {
>     switch( progEv.type ) {
>         case "load" :
>         // do something specific.
>        break;
>     }
> }
> 
> It is no doubt that someone would eventually do this. It is impossible
> from preventing people from programming badly. Is this a reason for
> omitting it from the API?
> 
> Charles, if I've misunderstood you, please explain. I am not trying to
> set up a straw man.
> 
> Garrett
> 
>> Since progress events are used by other specs, they can add a done if they
>> really want. But it turns out that for example XHR has onreadystate change
>> which you can use to get the same info.
>>
>> What do others think?
>>
>> Cheers
>>
>> Chaals
>>
>> ------- Forwarded message -------
>> From: "Garrett Smith" <dhtmlkitchen@gmail.com>
>> To: "Křištof Želechovski" <giecrilj@stegny.2a.pl>
>> Cc: whatwg@whatwg.org, chaals@opera.com
>> Subject: Re: [whatwg] Progress Events "done" event
>> Date: Mon, 10 Sep 2007 23:33:20 +0200
>>
>> On 8/27/07, Křištof Želechovski <giecrilj@stegny.2a.pl> wrote:
>>> Remember that JavaScript is a programming language after all.  You can
>>> use a
>>> loop to get rid of the repetitions.
>>> Start from
>>> var done = ["load", "error", "abort"]...
>>> and apply the closure image.aEL(?, hPB, false) to it.
>>> Sincerely,
>>> Chris
>>>
>> That is true, in fact, it would also be possible to use Array.forEach
>> on that array.
>>
>> The disadvantage is that it still invites code repetition. It is less
>> concise.
>>
>> On the contrary:
>>
>> xhr.addEventListener("done", callCompleteHandler, false);
>> function callCompleteHandler(e) {
>>
>> }
>>
>> Translates the use case to code quite naturally.
>>
>>
>> I like to make these examples that are conceptually similar:
>>
>> "I'm going to call my friend and then I'm going to the dry cleaner."
>> vs.
>>
>> "I'm going to call my friend and if she's not available, after that,
>> I'm going to the dry cleaner and if the call failed, after that, I'm
>> going to the dry cleaner, and if we talk for a bit, after that...
>>
>> You get the point. English doesn't have loops or generators (hey
>> wouldn't that be cool!).
>>
>> My point is that having a done event is more concise and makes
>> realizing the use-case requirement to code more explicit.
>>
>> Garrett
>>
>>> -----Original Message-----
>>> From: whatwg-bounces@lists.whatwg.org
>>> [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Garrett Smith
>>> Sent: Sunday, August 26, 2007 8:25 AM
>>> To: whatwg@whatwg.org
>>> Cc: chaals@opera.com
>>> Subject: [whatwg] Progress Events "done" event
>>>
>>>
>>> ==========================================
>>> function showImage(imageHref) {
>>> ...
>>>
>>> // remove the progress bar when done.
>>>        image.addEventListener("load", hideProgressBar, false);
>>>        image.addEventListener("error", hideProgressBar, false);
>>>        image.addEventListener("abort", hideProgressBar, false);
>>> }
>>> ==========================================
>>>
>>> This is somewhat verbose. Clearly, the author is forced to repeat
>>> himself when all he really wants to do is hide the progress bar after
>>> the call is done.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>    Charles McCathieNevile, Opera Software: Standards Group
>>    hablo español  -  je parle français  -  jeg lærer norsk
>> chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)
>>
> 
>

Received on Monday, 21 July 2008 09:36:35 UTC