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

On Thu, 1 Mar 2012, Victor Carbune wrote:
> 
> The parser rules in WebVTT currently do not abort the steps if the
> collected WebVTT timestamp for 'start time' is greater or equal than
> 'end time':
> "4. Collect a WebVTT timestamp. If that algorithm fails, then abort
> these steps and return failure. Otherwise, let cue's text track cue
> start time be the collected time.
> [...]
> 10. Collect a WebVTT timestamp. If that algorithm fails, then abort
> these steps and return failure. Otherwise, let cue's text track cue
> end time be the collected time."
> 
> However, in the same time, in the first section, in the WebVTT file
> format it is specified:
> "5. A WebVTT timestamp representing the end time offset of the cue.
> The time represented by this WebVTT timestamp must be greater than the
> start time offset of the cue."
> 
> Since the parser allows this situation, it seems we can end up with bad 
> cues loaded, but later in the spec it's unclear how the UA should handle 
> them in various situations.

In what specific cases is it unclear what should happen?


> Also, from a user's point of view I don't think they make a lot of 
> sense.

Indeed, that's why they're not conforming.


> Is such a situation intentionally possible in the spec or is it a minor 
> mistake?

Such a situation is possible because there's nothing we can do to stop 
authors from making mistakes. Whether we drop the cue when the cue is 
found to have negative duration, or leave it in the DOM as is, or somehow 
normalise the values so duration is zero or positive, etc, is merely a 
design trade-off. In this case, it turns out to be simpler to just leave 
the cues in the DOM than try to filter them out. 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.

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

Received on Wednesday, 25 April 2012 20:12:42 UTC