Re: Cues with 'start time' >= 'end time'

On Wed, Apr 25, 2012 at 10:32 PM, Ian Hickson <ian@hixie.ch> wrote:

>  There's no point filtering it in the parser if we don't keep it out in
> the
> various other ways they can get in.
>

There is, when there are no other ways they can get in (as with media
player implementations that don't expose the API).

> Doing this means that implementations which don't expose an API (eg.
> > media players) have smaller testing requirements; they only need to test
> > that they're discarded at the parser.
>
> Non DOM implementations can still discard them at the parser.
>

Only if they prove that doing so has equivalent results.

I think there's at least one case where dropping them at the parser is
different: pause-on-exit cues.


On Thu, Apr 26, 2012 at 11:56 AM, Victor Carbune
<victor.carbune@gmail.com>wrote:

> I was thinking about missed cues: the exit event is dispatched before
> the enter event.


This does seem like a problem: code should be able to depend on exit events
always being fired after the enter event for the same cue.  If reversed
cues are allowed, the exit event task will sort ahead of the enter event.

Also, for missed cues with start time = end time,
> even if it's common sense, any dispatch order is theoretically
> correct.
>

This is a separate issue, but I agree it seems like a problem.  The tasks
are sorted by time, so if the start and end times are the same, the enter
and exit events (which are being dispatched on the same iteration of the
algorithm) have an undefined order.

This part can probably be fixed just by specifying that the sort in step 12
of the playback position algorithm (in 4.8.10.8) is a stable sort (which
I'm guessing is what was intended).

-- 
Glenn Maynard