[whatwg] HTMLMediaElement load and autoplay

[Philip Jägenstedt]

On Wed, 2008-07-02 at 15:53 +0000, Ian Hickson wrote:
> On Wed, 2 Jul 2008, Philip Jgenstedt 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.)

OK, so in that case I suppose the requirement is to call load() sometime
during the parsing phase. This probably implies that the loadstart event
must be fired on all media elements before the load event is fired on
the owner document.

As a side note, we certainly can't want to wait for all media elements
to fire the load before firing it on the parent document event as that
may take several minutes or never happen at all -- breaking half of the
web that relies on this behavior.

> > 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?

That's not really necessary in my opinion.

> > 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.

Indeed, but it wouldn't be a spec violation to value automatic loads and
script-invoked loads slightly different internally. That said, it's not
a priority and I will reraise the question if it appears to be a real
need in the future.

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