This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Based on the description of a WebVTT timestamp here http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp I considered that all of the following ought to be valid timestamps for use in WebVTT cue timings: 00:22.000 22.000 10:34.000 634.000 I filed a issue against mozilla/vtt.js that it was not properly parsing WebVTT timestamp representing a time in seconds and fractions of a second here: https://github.com/mozilla/vtt.js/issues/323 They have suggested that this might be a bug in this portion of the spec which doesn't seem to allow for parsing a "WebVTT timestamp representing a time in seconds and fractions of a second" like "634.000". http://dev.w3.org/html5/webvtt/#dfn-collect-a-webvtt-timestamp Are timestamps in the form of 634.000 (for 634 seconds) valid or is there a bug somewhere in the spec with regards to this?
(In reply to Jason Ronallo from comment #0) > Based on the description of a WebVTT timestamp here > http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp > I considered that all of the following ought to be valid timestamps for use > in WebVTT cue timings: > > 00:22.000 > 22.000 > 10:34.000 > 634.000 22.000 and 634.000 are not valid per the syntax, please let us know which part is not clear so that we can fix it. > I filed a issue against mozilla/vtt.js that it was not properly parsing > WebVTT timestamp representing a time in seconds and fractions of a second > here: > https://github.com/mozilla/vtt.js/issues/323 > > They have suggested that this might be a bug in this portion of the spec > which doesn't seem to allow for parsing a "WebVTT timestamp representing a > time in seconds and fractions of a second" like "634.000". > http://dev.w3.org/html5/webvtt/#dfn-collect-a-webvtt-timestamp > > Are timestamps in the form of 634.000 (for 634 seconds) valid or is there a > bug somewhere in the spec with regards to this? (In reply to Jason Ronallo from comment #0) > Are timestamps in the form of 634.000 (for 634 seconds) valid or is there a > bug somewhere in the spec with regards to this? It's not valid per the syntax. The parsing is defined in http://dev.w3.org/html5/webvtt/#dfn-collect-a-webvtt-timestamp and it agrees with the syntax.
This section says that a WebVTT timestamp can be a "WebVTT timestamp representing a time in seconds and fractions of a second." http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp Then this: http://dev.w3.org/html5/webvtt/#dfn-partial-webvtt-timestamp "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." The description of how this is calculated suggests that it means something like 22.000 or 634.000 could be a valid timestamp. And then a WebVTT cue timing (http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue-timings) is made up of WebVTT timestamps. If a WebVTT timestamp can be just seconds and fractions of a second in one description in the spec, then why is it not a valid timestamp for a part of a cue timing? So when you are to "Collect a WebVTT timestamp" the kind of timestamp defined as seconds and fractions of a second (http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp) does not appear to work for these parsing steps. If a "WebVTT timestamp representing a time in seconds and fractions of a second" is never valid as part of a cue timing, then why define it at all in the spec?
Right. We allowed the syntax for specifying time to be either of the two, but did not add the parsing for it in http://dev.w3.org/html5/webvtt/#dfn-collect-a-webvtt-timestamp .
http://dev.w3.org/html5/webvtt/#dfn-partial-webvtt-timestamp is very strange. The definition is neither syntax nor parsing, just some rules about how to convert a floating point number into hours, minutes, seconds and seconds-frac. Since "WebVTT timestamp representing a time in seconds and fractions of a second" isn't actually used anywhere I think it should simply be removed from the spec.
See PR at https://github.com/w3c/webvtt/pull/203
Patch landed