Re: [whatwg] HTMLMediaElement load and autoplay
On Thu, 3 Jul 2008, Philip J�genstedt wrote: 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. Yes, typically. 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. Right; the spec says only things that delay the load event delay the load event, and video isn't one of them. 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. Ok. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTMLMediaElement load and autoplay
Keeping video discussion on the whatwg list as Firefox and Apple implementors seem to be listening here... I have some issues with the load method and when it is invoked. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#load As far as I can see, there are 6 distinct ways that the method can be invoked: Immediate: - User invoked the DOM load() method - In the play() method, if the media element's networkState attribute has the value EMPTY - In the pause() method, if the media element's networkState attribute has the value EMPTY As soon as all other scripts have finished executing: - If a media element whose networkState has the value EMPTY is inserted into a document - If the src attribute of a media element that is already in a document and whose networkState is in the EMPTY state is added, changed, or removed - If a source element is inserted into a media element that is already in a document and whose networkState is in the EMPTY state 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? As far as I can tell, there is no other way the autoplay mechanism could work. If automatic loading is the intention, at what time is it supposed to happen? I suggest: as soon as the DOM is in a consistent state, after the DOMContentLoaded event is fired (where supported). The reason being of course that media content isn't DOM content as such and DOMContentLoaded shouldn't have to wait longer than necessary. I think this is the best option, as it is consistent -- load is always invoked automatically irrespective of if the media element was in the markup or inserted via DOM. 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? 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. -- Philip Jägenstedt Opera Software
Re: [whatwg] HTMLMediaElement load and autoplay
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLMediaElement load and autoplay
On Wed, 2008-07-02 at 15:53 +, 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
