[whatwg] <video> loading algorithms

[Ian Hickson]

On Tue, 3 Aug 2010, Boris Zbarsky wrote:
> On 8/2/10 5:20 PM, Ian Hickson wrote:
> > > Or does "stop the currently running task" in #spin-the-event-loop 
> > > imply a jump to step 2 of the algorithm under #processing-model2?
> > 
> > Yes.
> 
> OK, that might be worth clarifying.

Done.


> > > (Note: I still have a problem with the way "pause" is defined here, 
> > > but I've raised that before, I believe.)
> > 
> > I think we all have a problem with "pause", but I don't know what we 
> > can do about it. I don't have any pending feedback from you on this 
> > topic, as far as I can tell.
> 
> Odd.  I definitely sent something about it (in particular that it 
> doesn't seem very easily implementable in terms of network event 
> behavior, if the pause is waiting on a network event and other network 
> events need to not be delivered in the meantime).

The "pause" thing is never invoked when waiting for network behaviour on 
the same event loop. (That wouldn't work, as you point out.)


On Wed, 4 Aug 2010, Chris Pearce wrote:
> On 4/08/2010 11:32 a.m., Ian Hickson wrote:
> > 
> > > In the case of a tasks which invokes an algorithm which has a 
> > > synchronous section, and then pauses the event loop (such calling 
> > > window.alert()), we should not run the synchronous section until the 
> > > event loop pause has completed?
> >
> > Currently, yeah. We might want to make "pause" also trigger 
> > synchronous sections, if that's a problem.
> 
> Having "pause" trigger synchronous sections is definitely easier for us 
> to implement, and would make pausing the event loop consistent with 
> spinning the event loop WRT synchronous sections.

Ok, done.


On Wed, 4 Aug 2010, Philip Jägenstedt wrote:
> On Tue, 03 Aug 2010 17:40:33 +0200, Boris Zbarsky <bzbarsky at mit.edu> 
> wrote:
> > On 8/3/10 4:27 AM, Philip Jägenstedt wrote:
> > > For the record, here's how I interpreted "await a stable state":
> > > 
> > > The only state that is not stable is a running script.
> > 
> > I don't think that's true; for example you could be in an unstable 
> > state if you're in the middle of the parser inserting some nodes into 
> > the DOM.
> 
> If the parser running in considered an unstable state, then we would 
> have to wait until the whole document has finished parsing before 
> running the resource selection algorithm.

No, the parser is defined in terms of tasks and its interaction with the 
event loop (including what is a stable state) is defined.


> Thus, <video> would be unnecessarily delayed in a way that <img> isn't.

Actually <img> waits for much the same thing. :-) (Its rendering is 
updated when the event loop spins, which is around the same time as what 
is called a "stable state".)


> > > Therefore, when reaching that step, if the resource selection 
> > > algorithm was triggered by a script, wait until that script has 
> > > finished and then continue.
> > 
> > Per spec as currently written, this will give the wrong behavior.  
> > For example, if the script in question calls showModalDialog, this is 
> > supposed to interrupt the script task and spin the event loop, and so 
> > your synchronous section would need to run while the modal dialog is 
> > up.  It doesn't sound like your implementation does that.
> 
> That could be, but is this behavior actually useful for anything? It's 
> certainly simpler to implement and more predictable for authors to 
> always wait until the current script has finished executing.

Consider trying to play a sound in the background while the dialog is up, 
for instance.


On Tue, 24 Aug 2010, Philip Jägenstedt wrote:
>
> [Step 3 of the Otherwise clause at the end of the "An end tag whose tag 
> name is "script"" section of The "text" insertion mode.]
> 
> Should this step be read as
> 
> while (there is no style sheet blocking scripts and the script's "ready to be
> parser-executed" flag is set) {
>  Spin the event loop
> }
> 
> or
> 
> do {
>  Spin the event loop
> } while (there is no style sheet blocking scripts and the script's "ready to
> be parser-executed" flag is set)

It was meant to be the former. I've fixed it.


> In other words, will the synchronous section always be executed?

Not in between one <script> and a <script> that was document.write()ten by 
that script, no, not always.


> I think I meant to say that it if the synchronous section has run 
> depends on "whether or not the parser happened to return to the event 
> loop before the script". In other words, networkState could be 
> NETWORK_NO_SOURCE, NETWORK_EMPTY or NETWORK_LOADING here. Hopefully all 
> my conclusions are incorrect and there's actually a guarantee that the 
> synchronous sections runs before any scripts execute, see above.

There is not such a guarantee.


On Thu, 26 Aug 2010, Silvia Pfeiffer wrote:
> 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?

Er, yes! Oops.


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

Yes, but not for the purpose of reloading, only for the purpose of loading 
the resource in the first place.


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

Well that's not quite accurate either... it does it if the networkState is 
NETWORK_EMPTY, which can happen in a variety of conditions. I'm open to 
changing this text (from "if necessary" which is what it says now) but I 
really don't know what to change it to that would be both accurate and 
helpful.


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

The difference is that the first time there's nothing loaded, so to play() 
anything you have to load it, whereas the second time there's already 
something loaded, which play() can just play straight away without having 
to load anything first.


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

I can add it to the spec too if you think that would help. Where would a 
good place for it be?

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