[whatwg] Restarting the media element resource fetch algorithm after "load" event

[Robert O'Callahan]

On Fri, Oct 9, 2009 at 8:32 PM, Philip Jägenstedt <philipj at opera.com> wrote:

> Aesthetics is not a serious argument. More importantly, the progress events
> spec [1] requires that exactly one of error/abort/load be fired followed by
> loadend. Dropping load and loadend would be a willful violations of that
> spec. In my opinion, the progress events spec should be the one to change.
>
> [1] http://www.w3.org/TR/progress-events/
>

I agree.

That spec says

> If the Operation successfully completes, the user agent *must* dispatch a
> load event.
>
Here we're just dealing with an operation that never completes. The only
real problem in the spec is that it says "Exactly one of these *must* be
dispatched", which seems to just not have considered the possibility of
operations that run indefinitely.

Some other Mozilla developers have actually argued that progress events in
general don't make sense for media elements. The 'buffered' TimeRanges
attribute gives you much more accurate and useful information than progress
events. The progress event 'loaded' and 'total' attributes don't make a lot
of sense in implementations where data may be discarded and redownloaded
during the load. (If you discard some data, does the next progress event
have a smaller 'loaded' value than the last one? Or does 'total' increase by
the size of the discarded data?) But I don't want to open that can of worms
just yet :-).

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091009/b8605092/attachment.htm>