Re: Progress event spec

On Jan 29, 2007, at 7:58 AM, Charles McCathieNevile wrote:

>
>>> 2. Remove the preload and postload events.
>>>
>>> You know when it finished, because the load event or whatever is
>>> spitting out
>>> progress will have finished. You know when it started, because  
>>> you got a
>>> progress event.
>> The above text is meaningless: loadprogress being optional, you  
>> need a
>> "load-is-beginning" and "load-is-complete" event that are  
>> mandatory. So
>> what are you doing ? Removing the mandatory first and last event, or
>> having them all called the same ?
>>
>> The use case for indeterminate length and you want to have the end  
>> event
>> is: you get a live recording. And I would want to know if it is  
>> the end
>> or just progress. So I really think that removing postload, or at  
>> least
>> the clear indication of an end, is a mistake.
>
> progress events are fired because you already have some other  
> operation in
> progress, which will start and finish. For something like an HTTP  
> connection
> where you take a couple of seconds to establish the connection it  
> would be
> useful to fire a progress event with zero bytes loaded.
>
> In the case of doing this for a connection where you don't know the  
> length, this
> will be indistinguishable from a (now presumably completed) zero- 
> length transfer.
> But since the transfer has presumably finished, what kind of UA  
> would actually
> fire such a pointless event? It already *must* fire the load event,  
> which you
> can trap to note that your loading is finished.
>
> So the assumption behind the above combination is that it is a  
> justifiable hack.
> I certainly haven't seen any use case for the zero-length transfer  
> to fire a
> progress event - if there is one, then of course this hack is not  
> good enough.

If such an event should never be fired, then the spec should say it  
MUST never be fired. Otherwise, you can't write interoperable code  
that does the right thing. But I think it's better to require  
distnictive start and end events. Otherwise you can't write the  
reusable progress control driven solely by events that I proposed as  
a use case.

Regards,
Maciej

Received on Monday, 29 January 2007 22:32:03 UTC