<a href="http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource">http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource</a><br><br>In the resource fetch algorithm, after we reach the NETWORK_LOADED state in step 3 which indicates that all the data we need to play the resource is now available locally, we end the resource fetch algorithm. However, in Gecko we have a media cache which might discard blocks of media data after we've reached the NETWORK_LOADED state (to make room for data for other loading resources). This means we might have to start fetching the resource again later. The spec does not seem to allow for this. Do we need to change our behavior, or does the spec need to change to accommodate our behavior? I'd prefer not to change our behavior since I think to follow the spec we'd need to pin the entire resource permanently in the cache after we reached NETWORK_LOADED, which could be highly suboptimal in some situations.<br>
<br>Another issue is that it's not completely clear to me what is meant by "While the user agent might still need network access to obtain
    parts of the <a href="http://www.whatwg.org/specs/web-apps/current-work/#media-resource">media
 resource</a> ..." What if there is data in the resource that we don't need in order to play through normally, but which might be needed in some special situations (e.g., enabling subtitles, or seeking using an index), and we optimize to not load that data unless/until we need it? In that case would we never reach NETWORK_LOADED?<br>
<br>In general NETWORK_LOADED and the "load" event seem rather useless and dangerous IMHO. If you're playing a resource that doesn't fit in your cache then you'll certainly never reach NETWORK_LOADED, and since authors can't know the cache size they can never rely on "load" firing. And if you allow the cache discarding behavior I described above, authors can't rely on data actually being present locally even after "load" has fired. I suspect many authors will make invalid assumptions about "load" being sure to fire and about what "load" means if it does fire. Does anyone have any use cases that "load" actually solves?<br>
<br>Rob<br>-- <br>"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]<br>