W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] <video> loading algorithms

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 26 Aug 2010 00:47:40 +1000
Message-ID: <AANLkTi=ebfUNgE6VM4H5Rbg=y44dticGuWsrBHuM51tK@mail.gmail.com>
On Tue, Aug 24, 2010 at 7:43 PM, Philip J?genstedt <philipj at opera.com>wrote:

> On Tue, 24 Aug 2010 10:24:35 +0200, Ian Hickson <ian at hixie.ch> wrote:
>  Given that, it wouldn't be a big problem to let modification of src
>>> attributes on source elements trigger resource selection, you won't get
>>> the 3-2-1 problem I mentioned earlier.
>> I don't really understand what use case this would solve.
> Neither do I, I'm just saying that it's easy to do if necessary.

I was running through all the properties that can possibly be changed in
JavaScript and checking which effects they have in all browsers, i.e. what
events they call etc. I wasn't aware that authors are discouraged from
changing @src on <source>.

On Tue, Aug 24, 2010 at 6:24 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 24 Jul 2010, Silvia Pfeiffer wrote:
> >
> > There is definitely a spec bug, because different locations of the spec
> > say diverging things.
> For the record, when the spec contradicts itself, and one part is
> normative (such as the algorithm here) and another is non-normative (such
> as the definitions here) then always assume the normative part is wrong. I
> often forget to update the non-normative parts.

You mean: the normative part is right, I assume?
Thanks for this clarification - I was indeed unaware of the history of

 On Mon, 26 Jul 2010, Silvia Pfeiffer wrote:
> >
> > I now wonder about the intention of play() (and also of pause()). As I
> > understood it, they are both meant to reload the media resource if
> > @currentSrc has changed, similar to what load() is supposed to do.
> I do not believe that has ever been the intent.

Both descriptions of play() and pause() have a "loading the media resource"
in them.
media . play<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-play>

Sets the paused<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-paused>attribute
to false, loading the media
beginning playback if necessary. If the playback had ended, will
it from the start.
media . pause<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-pause>

Sets the paused<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-paused>attribute
to true, loading the media
I assumed that if the @currentSrc had changed, that would trigger loading
the new media resource, too. If that is not the intention, maybe the
non-normative description should point out that it only triggers loading the
media resource when the @src attribute is being set for the very first time.
Though, to be honest, I don't really see a difference between setting @src
through JavaScript for the first time (which IIUC also has a NETWORK_EMPTY
state) and re-setting it again a subsequent time - IMHO both should
consistently either include the media resource loading or exclude it.

On Tue, 27 Jul 2010, Silvia Pfeiffer wrote:
> >
> > Sure, but this is only a snippet of an actual application. If, e.g., you
> > want to step through a list of videos (maybe an automated playlist)
> > using script and you need to provide at least two different formats with
> > <source>, you'd want to run this algorithm frequently.
> Just have a bunch of <video>s in the markup, and when one ends, hide it
> and show the next one. Don't start dynamically manipulating <source>
> elements, that's just asking for pain.
> If you really must do it all using script, just use canPlayType and the
> <video src=""> attribute, don't mess around with <source>.

Thanks for adding that advice. I think it's important to point that out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100826/86839cc3/attachment.htm>
Received on Wednesday, 25 August 2010 07:47:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC