- From: Dave Singer <singer@apple.com>
- Date: Fri, 16 Jan 2009 10:51:11 -0800
- To: Philip Jägenstedt <philipj@opera.com>, Simon Pieters <simonp@opera.com>, public-html <public-html@w3.org>
At 9:43 +0100 15/01/09, Philip Jägenstedt wrote: >Another option would be to have a current state >and a pending state, like several media >frameworks do. The state enumeration could be >NONE, PAUSED, PLAYING and one could have two >state variables currentState and pendingState. >The NONE state would be needed for pendingState >when there isn't actually a state transition in >progress and as the initial value for >currentState before the resource has loaded and >paused/played. The paused attribute would of >course no longer be needed. > >Philip I think this could also work (something in me nags that it's functionally equivalent). I kinda like the requested/active dichotomy as (for example) the autoplay attribute is then the initial value of requested, and so on. I also like both of these in that they reflect the truth in the states, as well as in events. I guess when a stall happens, you go into paused with play 'pending', it's not quite so semantically clear (to me) I think. But this is a nit. > >On Tue, 13 Jan 2009 21:57:05 +0100, Dave Singer <singer@apple.com> wrote: > >> >>We suggested a while back that there should be two state booleans >>play_requested >>play_in_progress >> >>instead of the one today (which is "paused"), >>which I think would cover this case as well as: >>* stalls in download or streaming, which today >>are only noticeable if you catch the 'waiting" >>event (there's no state change) >>* streaming protocols, which always lag between >>request and play (in download, this only >>happens if you ask for play before the stack >>has got far enough down the loading path) >> >>clearly !play_requested && play_in_progress >>should never occur, but the other three >>conditions can. >> >> >> >>At 16:20 +0100 13/01/09, Simon Pieters wrote: >>>This is related to http://www.w3.org/Bugs/Public/show_bug.cgi?id=6353 >>> >>> >>>Consider the following: >>> >>> <video id=v><script> >>> v = document.getElementById('v'); >>> v.src = 'test'; >>> v.play(); >>> </script> >>> >>>When the video start tag is parsed, load() is >>>implicitly invoked and when the method returns >>>(meaning scripts can potentially run before >>>the next steps in load() are run, AIUI) >>>networkState is NETWORK_LOADING. >>> >>>When setting the src attribute, load() will >>>not be implicitly invoked again because >>>networkState is not NETWORK_EMPTY. >>> >>>When play() is invoked, load() will still not >>>be implicitly invoked again because >>>networkState is not NETWORK_EMPTY. >>> >>>So the list of candidates will be empty and >>>nothing will play. This is not what one would >>>expect. (If you do an explicit load() before >>>play() it works as expected.) >>> >>> >>>We haven't found a nice way to fix this, yet. >>>Maybe play() should be async and set a flag >>>that some step at the end of the load() >>>algorithm will look at and, if set, start to >>>play the resource, or something. >>> >>>-- >>>Simon Pieters >>>Opera Software >> >> > > > >-- >Philip Jägenstedt >Opera Software -- David Singer Multimedia Standards, Apple Inc.
Received on Friday, 16 January 2009 18:52:48 UTC