W3C home > Mailing lists > Public > public-html-comments@w3.org > October 2009

Re: Video DOM API

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 14 Oct 2009 08:54:57 +0000 (UTC)
To: Gervase Markham <gerv@gerv.net>, Simon Pieters <simonp@opera.com>, Philip Jägenstedt <philipj@opera.com>, Arthur Clifford <art@artspad.net>, "Musgrove, Jason L" <J.L.Musgrove2@wlv.ac.uk>, "Michael A. Puls II" <shadow2531@gmail.com>
Cc: public-html-comments@w3.org
Message-ID: <Pine.LNX.4.62.0910140551480.25383@hixie.dreamhostps.com>
On Thu, 8 Oct 2009, Gervase Markham wrote:
> On a <video> element (I haven't tried <audio>), if you change the src= 
> attribute to a new file, you have to call .load() before .play(), 
> otherwise it replays the old file. This lost me half an hour of 
> debugging, and recently another person posted in the Mozilla newsgroups 
> having exactly the same problem.
> I am told by an informed source (Boris Zbarsky) that the spec for 
> <video> requires this behaviour. Having spent ten minutes reading the 
> highly comprehensive specification, I could not find the location where 
> it says this. However, I believe him :-)
> Question: why? This is counter-intuitive. Under what circumstances would 
> you want to set the src= attribute of a <video> tag to a file which you 
> did not want the loading process to begin immediately? Can we eliminate 
> the requirement, e.g. by having play() implicitly call load() if it 
> hasn't been called?

I've made setting .src stop the video and reload as you request.

It doesn't affect <source> processing, though.

On Thu, 8 Oct 2009, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is 
> set or changed. Should the "in a Document" check be removed, too? That 
> is, do you want to be able to do
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }
> ?
> (You wouldn't need to invoke play() again, because the media isn't 
> paused when it has ended.)

It calls load(), so you do have to do the check.

On Sat, 10 Oct 2009, Simon Pieters wrote:
> On Fri, 09 Oct 2009 18:34:02 +0200, Gervase Markham <gerv@gerv.net> 
> wrote:
> >
> > I just want play() to implicitly invoke load(), because then it all 
> > DWYM.
> Even if the first video hasn't ended yet? Even if src hasn't changed?

On Sat, 10 Oct 2009, Gervase Markham wrote:
> Well, if src hasn't changed, then presumably load() is a no-op under any
> circumstances?

load() always restarts the entire loading algorithm.

> If a video is playing, I change the src= and then call play() again, I don't
> think it's unreasonable to expect the element to start playing the new src.

play() maps to the play button in the UI. So if made it wait until play() 
was called, then the script could change the src, not call play(), and 
then the user would find that if he hit pause and then play again, it 
would suddenly load the new video. That would be rather weird.

On Thu, 8 Oct 2009, Arthur Clifford wrote:
> Wouldn't it be easier to have play take an optional src parameter?
> var a=new Audio();
> a.onended = function() { if(a.src=='foo') a.play('bar'); }
> a.play('foo');
> internally play could do this check:
> if( inSrc !== src) src=inSrc ... load and play video
> else if at end of audio, rewind and play
> else play forward from where the playback head is at.

We could do that, but that would be redundant with setting src="" (which 
we can't really remove), so I don't see much point.

On Thu, 8 Oct 2009, Musgrove, Jason L wrote:
> If what is being aimed for is the sequential playing of more than one 
> media item, why not amend the spec such that the appropriate media 
> element (either <audio> or <video>) be permitted to have child elements 
> that define a playlist in lieu of a src attribute (which can still be 
> used if only one media item is to played), and let the browser take care 
> of the sequencing without the unnecessary addition of script to do this.
> Suggested example:
> <video>
> 	<clip src="video1.m4v" />
> 	<clip src="video2.m4v" />
> </video>
> The API could then be augmented to include a ".clips" property which 
> represents a collection of the clip elements, and provides appropriate 
> methods to manipulate the "playlist".

Playlists are on the cards for v2.

On Wed, 14 Oct 2009, Michael A. Puls II wrote:
> I am that other person and here's what I personally expect, fwiw:
> When setting src:
> 1. The current media should stop playing.
> 2. It should then be unloaded.
> 3. All states should be reset (including the play state).
> 4. The new media should start loading.
> 5. If autoplay is true, the new media should start playing. If not, it 
> only starts playing when you call play().

That is now the case.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 October 2009 08:43:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:25 UTC