[whatwg] <video> loading algorithms

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Wed Aug 25 07:47:40 PDT 2010


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


 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
resource<http://www.whatwg.org/specs/web-apps/current-work/complete.html#media-resource>and
beginning playback if necessary. If the playback had ended, will
restart
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
resource<http://www.whatwg.org/specs/web-apps/current-work/complete.html#media-resource>if
necessary.
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.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100826/86839cc3/attachment-0002.htm>


More information about the whatwg mailing list