Re: [whatwg] Progress Events "done" event

On Mon, Jul 21, 2008 at 2:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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).
>

Yes, that is the case. The load is finished, and there is some sort of
icon for "loading". This sometimes appears as an overlay that prevents
user interaction with certain components.

The desire is for a generalized handling for "done".

The handling would be to remove the "loading" overlay message,
regardless of the status of the response. It's sort of like a
"finally" clause.

> 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").
>

"finish" and "end" sound fine, but "loadfinish" sounds like something
loaded (to me, at least). I can see how "done" doesn't fit into scheme
for events. How about "complete"?

If the "complete" event fires before fail or succeed fire then the
"please wait, loading" would be removed first. That seems to be the
more desirable effect to fulfill the use case.

Garrett

> / 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 Sunday, 31 August 2008 03:45:34 UTC