On Thu, 26 Mar 2009, Matthew Gregan wrote: > At 2009-03-25T10:16:32+0000, Ian Hickson wrote: > > On Fri, 13 Mar 2009, Matthew Gregan wrote: > > > It's possible that neither a 'play' nor 'playing' event will be fired > > > when a media element that has ended playback is played again. When > > > first played, paused is set to false. When played again, playback has > > > ended, so play() seeks to the beginning, but paused does not change (as > > > it's already false), so the substeps that may fire play or playing are > > > not run. > > > > 'playing' should fire, though, since the readyState will have dropped down > > to HAVE_CURRENT_DATA when the clip is ended, and will drop back up to > > HAVE_FUTURE_DATA after seeking. > > Right, so your intention is to interpret it thusly: readyState becomes > HAVE_CURRENT_DATA when playback ends because it's not possible for the > playback position to advance any further, and thus it's not possible to have > data beyond the current playback position (which HAVE_FUTURE_DATA is > predicated upon). > > Makes sense, but can the spec be made clearer about the behaviour in this > case? HAVE_FUTURE_DATA talks about "advancing *without reverting to > HAVE_METADATA*", which doesn't apply in this case because we have all the > data available locally.
Clarified. > Based on that interpretation, when the user sets playbackRate to -1 > after playback ends, the readyState would change from HAVE_CURRENT_DATA > to HAVE_FUTURE_DATA because the current playback position can now > advance. I've made a bunch of changes to fix how things work when the direction of playback is backwards; there were some odd things in the way it was defined before (for example the previous definition actually had the playback position go infinitely negative and didn't stop at the start of the clip!). > Following this logic, if playbackRate is set to 0 at any time, the > readyState becomes HAVE_ENOUGH_DATA, as advancing the playback position > by 0 units means the playback position can never overtake the available > data before playback ends. Except this case seems to be specially > handled by: > > "The playbackRate can be 0.0, in which case the current playback > position doesn't move, despite playback not being paused (paused > doesn't become true, and the pause event doesn't fire)." > > ...which uses the term "move" rather than "advance", but suggests that > the concept of the playbackRate advancing by 0 isn't consider advancing, > which seems logical. I've clarified the uses of "advance" that I could find. Let me know if the spec is still ambiguous. Thanks! -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
