[whatwg] HTMLMediaElement load and autoplay

[Ian Hickson]

On Wed, 2 Jul 2008, Philip Jägenstedt wrote:
> 
> It is not clear if the user agent should automatically invoke the load 
> method on media elements which are in the document's static markup. 
> »¿ï»¿Is it supposed to be implied by "media element ... inserted into a 
> document"?

Yes. The parser can be thought of as just another script manipulating the 
DOM; when it inserts the <video> element, start downloading video. (And if 
that didn't work, then try again when the first <source> is inserted, and 
then the second one, and so forth).

(It's fine to batch inserts too.)


> If user agents don't want to waste time downloading video that isn't 
> visible (e.g. due to CSS "display:none") they can block the download 
> (step 14 of the load algorithm) until it becomes visible. In this 
> situation, does the spec allow firing the stalled event immediately 
> instead of waiting 3 seconds?

Sure. The 3 seconds is just an "about". 0 seconds is "about" 3 secods. :-) 
Would you like the spec to be more explicit about this?


> Since "faking it" is allowed, script authors should be aware that 
> loading media (at least video) in the background isn't going to work. 
> I'm not sure if this might be a problem, but if it is I expect we could 
> cater to that need by making an explicit load() to cause the user agent 
> to rush to CAN_PLAY as fast as possible without fake-stalling.
> 
> Any ideas on this? This might be nit-picking, but consistency across 
> browsers would be nice if possible.

The script can tell if the download is being blocked by checking 
bufferingThrottled and bufferingRate. I'm not sure we want a way to 
override the blocking since it is supposed to represent user intent.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'