- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 09 Apr 2009 10:49:33 +0200
- To: public-html@w3.org
Some feedback on the big batch of changes to media elements made in March. 1. may never load Previously there were many conditions for when to implicitly invoke the load() method, e.g. when a media element was inserted into a document. This was all replaced by the resource selection algorithm, but as far as I can see that algorithm is only invoked by an explicit load() and in the Audio(src) constructor. In other words, there's nothing to cause e.g. <video autobuffer autoplay> to either begin buffering or playing unless a script explicitly calls load() or play() on it. For simplicity I would prefer that the resource selection algorithm be started for any media element, regardless of whether it has any src/source, is in a document or any other conditions. This makes all of the below equivalent: <audio src="foo"> a=new Audio("foo"); a=new Audio(); a.src="foo"; a=document.createElement("audio"); a.src="foo"; This behavior isn't incredibly important in itself, but it removes the need for special cases in the Audio constructor or elsewhere. Ignoring whether or not the media element is in a document when invoking the resource selection/fetch algorithm makes sense for preloading, etc so I don't think we should reintroduce that. 2. may load the wrong source Futher, I think it's necessary to add a clause after step 1.4 that the script which modified src/source must complete before the (now asynchronous) resource selection algorithm continues. Otherwise, a script like... a.src="audio.ogg"; <!-- async algorithm could set NETWORK_LOADING and run step 3-4 --> if (condition) a.src+="?t=0:00:10/0:00:20"; else a.src+="?t=0:00:20/0:00:30"; ...might cause "audio.ogg" to be loaded even though it wasn't even a candidate. It's a race condition, but even for more trivial cases allowing the script to first finish modifying the DOM must give a more predictable behavior. 3. about MEDIA_ERR_NONE_SUPPORTED Simon has suggested [1] and Ian confirmed [2] that <video> <source src=1> <source src=2> ... <source src=n> Can generate n-1 error events with error code MEDIA_ERR_NONE_SUPPORTED on a slow network. This seems like a very bad behavior as authors are likely to use this error to determine if they need to replace the element with fallback content. The slow network issue is likely to be overlooked and even if the author is aware of it it's not trivial to determine if you got the error because of the network or because there really was no supported source. We first suggested firing one error event for each source that isn't supported, adding the URL of the unsupported resource to MediaError object. That might be overkill, but there must instead be a guarantee that the event only fire once and only if no more <source> tags are going to trickle in over the network. It's quite simple to just keep waiting if the <video> tag hasn't been closed yet, but I'm not sure how such a requirement can be stated in terms of DOM. Ideas? [1] http://lists.w3.org/Archives/Public/public-html/2009Mar/0201.html [2] http://lists.w3.org/Archives/Public/public-html/2009Mar/0629.html -- Philip Jägenstedt Opera Software
Received on Thursday, 9 April 2009 08:49:32 UTC