<div>Chiming in here from Chrome's perspective...</div><div><br></div><div>We use a combination of in-memory and block-based caching for media resources. There is no guarantee whatsoever on what is loaded. There's a nice side benefit of allowing complete random access to the file if the server supports range request (in my opinion a must if you're working on an audio/video site, but that's a side issue).</div>
<div><br></div><div>For http:// we don't support load at all and never reach NETWORK_LOADED. We're also baffled at what to report in our progress events because the numbers are seemingly useless in our context. Sometimes we'll cache the end of the file to grab some useful metadata, but we don't want to fire a progress event saying we've loaded the last bit of the file...</div>
<div><br></div><div>For file:// we immediately transition to NETWORK_LOADED. This is how we pass the WebKit layout tests :)</div><div><br></div><div>Being the only browser (I think?) that doesn't fire the load event we've ran into site compatibility issues. I believe a lot of web authors are used to tacking onload= into a tag and expecting it to work. I've reached out to web authors to educate them about using canplaytype() + oncanplay/oncanplaythrough as alternatives to user agent checking and onload.</div>
<div><br></div><div>I'm in favour of getting rid of both load and progress events.</div><div><br></div><div>Andrew</div><div><br></div><div><div class="gmail_quote">On Fri, Oct 9, 2009 at 2:27 AM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Fri, Oct 9, 2009 at 8:32 PM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a>></span> wrote:<br>
</div><div class="im"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
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.<br>
<br>
[1] <a href="http://www.w3.org/TR/progress-events/" target="_blank">http://www.w3.org/TR/progress-events/</a><font color="#888888"></font><br></blockquote></div><br clear="all"></div>I agree.<br><br>That spec says<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
If the Operation successfully completes, the user agent <em>must</em>
dispatch a <code>load</code> event.<br></blockquote>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 <em>must</em> be
dispatched", which seems to just not have considered the possibility of operations that run indefinitely.<br><br>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 :-).<div>
<div></div><div class="h5"><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>
</div></div></blockquote></div><br></div>