- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 1 Nov 2007 00:43:29 +0000 (UTC)
On Wed, 31 Oct 2007, Dave Singer wrote: > > "When the current playback position of a media element changes (e.g. due > to playback or seeking), the user agent must run the following steps. If > the current playback position changes while the steps are running, then > the user agent must wait for the steps to complete, and then must > immediately rerun the steps. (If one iteration takes a long time, this > can cause certain ranges to be skipped over as the user agent rushes > ahead to "catch up".) " > > Perhaps the parenthesized comment could be prefixed: (These steps are > taken as often as possible or needed; if one iteration takes a long > time, ...)? Just a thought. Added. > "3. If none of the cue ranges in current ranges have their "active" > boolean set to "false" (inactive) and none of the cue ranges in current ranges > have their "active" boolean set to "true" (active), then abort these steps. " > > one rather suspects that "other ranges" is intended for the second test? Fixed. > "5. If there are any cue ranges in other ranges that have their "active" > boolean set to "true" (active) and have their "pause" boolean set to "true" as > well, then immediately act as if the element's pause() method had been > invoked. " > > Does the pause boolean add much over the exit handler? It seems that if the > exit is because of a seek, it might be kinda odd to immediately pause again? Hm, yeah, good point. The original use case for 'pause' was that it's very hard to have frame-accurate pausing if we rely on scripts to do it. I've changed the spec a bit so that the pausing only happens during normal playback, seeking won't trigger it anymore. Is that ok? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 31 October 2007 17:43:29 UTC