[whatwg] minor comments on media element cue ranges

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'