mozilla / vtt.js

A JavaScript implementation of the WebVTT specification

Home Page:http://dev.w3.org/html5/webvtt/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

follow spec for timestamps that are seconds and fractions of a second

jronallo opened this issue · comments

Currently if timestamp is in the form of 22.000 it is not parsed correctly. Only timestamps that have at least the minutes piece like 00:22.000 are parsed correctly. The spec allows for both forms.

http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp

That's a bug in the spec I believe, or at least isn't explained properly. If you look just below that you'll see the definition for it:

A WebVTT timestamp representing a time in seconds and fractions of a second is a WebVTT
timestamp representing hours hours, minutes minutes, seconds seconds, and thousandths of a
second seconds-frac, calculated as follows

A WebVTT timestamp representing time in seconds and fractions of a second is a WebVTT timestamp representing hours, minutes, seconds, and thousandths of a seconds. They're both written the same way, but interpreted differently.

You can see how that is done here in the parsing portion of the specification for a timestamp.

Yes, reading the parsing steps does not seem to allow for a timestamp in the form of 634.000 if I'm reading them correctly but then the language in other places isn't so clear or I'm not familiar enough with some specific meaning of the terms used in the text.

I've filed an issue here to try to get resolution on this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25542

Oh, no sorry. I meant that it doesn't allow for it and that the note you were referring to was unclear. The parsing section requires at least two strings of digits before the fraction portion. It optionally allows a third string of digits two characters in length. So the timestamp must be in the form of 00:00.000 or 00:00:00.000.

I'd keep the spec bug open though if you'd like to get timestamps with a format of 00.000 added to the spec.

I'm going to close this bug since the spec disallows this. We'll definitely implement this feature if it's added to the spec though.