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

On Thu, 26 Apr 2012, Silvia Pfeiffer wrote:
> On Thu, Apr 26, 2012 at 1:34 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 26 Apr 2012, Silvia Pfeiffer wrote:
> >> >>
> >> >> It also makes it easier for cue editors to use the parser and API 
> >> >> without having to worry about losing cues that happen to have 
> >> >> incorrect timings.
> >> >
> >> > I don't see the value.  If it's an invalid cue, then it's no 
> >> > different than losing a cue that happens to have a syntax error.
> >>
> >> In fact, if we don't lose it, they may never notice their mistake, 
> >> seeing as it ends up in the cue list structure.
> >
> > I'm not sure who "they" means here. A cue editor that wants to expose 
> > this can trivially do so by just showing all cues with negative 
> > durations.
> 
> I meant the WebVTT file authors with "they". I was mostly thinking about 
> those that use a Web browser to author their files and look at what 
> JavaScript lists for finding out whether their cues got parsed. A more 
> intelligent editor should indeed expose the problems during authoring.

If an author is going to so much trouble as to use or find a tool that 
loads up the VTT file then walks through its DOM to show the various cues, 
but yet does not actually watch those cues in the video itself to check 
the timings, I think it's reasonable to expect that such an author would 
already be taking into account such potential mistakes. But in any case, I 
am skeptical that this kind of author would be common.


On Thu, 26 Apr 2012, Victor Carbune wrote:
> On Thu, Apr 26, 2012 at 6:34 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 26 Apr 2012, Silvia Pfeiffer wrote:
> >>
> >> I agree. Keeping such faulty cues in the objects will just result in 
> >> a need for extra error handling in the browsers and other 
> >> implementations, which have to continuously check if the next cue in 
> >> the TextTrackCueList is valid before attaching callbacks and doing 
> >> rendering etc.
> >
> > Actually, if they just implement the spec, it all just works, as far 
> > as I can tell. The algorithms mostly don't even need to check for 
> > this.
>
> I was thinking about missed cues: the exit event is dispatched before 
> the enter event.
>
> Also, for missed cues with start time = end time, even if it's common 
> sense, any dispatch order is theoretically correct.
>
> If there's some extra logic in the web page that depends on this order, 
> it might lead to complications.

Thanks for pointing these out. I have now addressed these issues.


On Thu, 26 Apr 2012, Glenn Maynard wrote:
> 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).

And such implementations can already drop them.


> > > 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.

That's what implementing a spec is about. Finding way to efficiently 
implement the algorithms written in the spec in a way that results in the 
same output as the spec.


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

Pause-on-exit cues don't exist without the API.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'