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

Robert O'Callahan robert at ocallahan.org
Thu Oct 8 14:08:32 PDT 2009

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

> The spec notes that "Some resources, e.g. streaming Web radio, can never
> reach the NETWORK_LOADED state." In my understanding, you mustn't go to
> NETWORK_LOADED if you can't guarantee that the resource will remain in
> cache. Browsers with clever caching or small caches simply won't send a load
> event most of the time.

Right, HTML5 allows Gecko to simply never enter the NETWORK_LOADED state and
send a "load" event. That would be the simplest thing for us to do, and I
think the best in terms of letting us do intelligent caching. But I'd prefer
not to do it alone.

Aesthetically, however, I think it would be strange to not have the load
> event.

If you mean because of the analogy with the "load" events of other elements,
then I strongly disagree. That analogy is itself the dangerous thing about
media element "load" events: the name strongly suggests you can use them the
same way as the "load" events for, say, documents, whereas in reality you
can't, in particular because you cannot rely on the "load" event eventually
firing. (The fact that the "load" event will usually fire during testing
makes it even more dangerous.)

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091009/dbea99db/attachment-0002.htm>

More information about the whatwg mailing list