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

I personally think it makes sense to drop such cues on the floor,
since they should not have any influence on anything, never being
active.

Or does anyone have a use case?

Cheers,
Silvia.

On Thu, Mar 1, 2012 at 11:19 AM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> Hello,
>
> 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.
>
> Also, from a user's point of view I don't think they make a lot of sense.
>
> Is such a situation intentionally possible in the spec or is it a minor mistake?
>
> Best regards,
> Victor
>

Received on Thursday, 1 March 2012 07:34:21 UTC