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
