[whatwg] HTMLMediaElement load and autoplay
ian at hixie.ch
Wed Jul 2 08:53:26 PDT 2008
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg