I filed this bug while reviewing the WebVTT spec for implementation in a JS subtitle engine which already works with .SRT. I was not able to find any reasoning for WebVTT's change to a period for the seconds-frac separator.

SRT: hh:mm:ss,fff
WebVTT: hh:mm:ss.fff

I think that re-use of existing SRT tools and implementation of subtitle interpreters would be much helped if we could adopt the SRT version for the timestamp format. Thanks!

(In reply to comment #1)
> I filed this bug while reviewing the WebVTT spec for implementation in a JS
> subtitle engine which already works with .SRT. I was not able to find any
> reasoning for WebVTT's change to a period for the seconds-frac separator.
> 
> SRT: hh:mm:ss,fff
> WebVTT: hh:mm:ss.fff
> 
> I think that re-use of existing SRT tools and implementation of subtitle
> interpreters would be much helped if we could adopt the SRT version for the
> timestamp format. Thanks!

For the sake of allowing denser time specifications in caption files, it would actually make sense to have a flexibler time specification such as

[[h*:]mm:]ss[.[d[c[m]]]  | s*[.d[c[m]]]

With the denser possibilities of specifying time in this way, it's no longer compatible with SRT anyway, which prescribes presence of hh and mm and fff.


Incidentally, there are some SRT files that use "." as the seconds-frac separator already, so existing SRT parsers should already be able to deal with that.

We used to support both "." and ",", but it was simplified to just "." when WebVTT stopped being intentionally compatible with SRT because it turns out SRT is way the heck more complicated than it appears to be. If it wasn't for SRT there really would be no reason to support "," as far as I can tell; formats like this usually use the US locale in their syntax.

foolip: do you want to add anything here? IIRC it was your idea to remove support for ",".

(In reply to comment #3)
> We used to support both "." and ",", but it was simplified to just "." when
> WebVTT stopped being intentionally compatible with SRT because it turns out SRT
> is way the heck more complicated than it appears to be. If it wasn't for SRT
> there really would be no reason to support "," as far as I can tell; formats
> like this usually use the US locale in their syntax.
> 
> foolip: do you want to add anything here? IIRC it was your idea to remove
> support for ",".

Short answer: I still think we should support only "." as the separator.

The only compatibility issue here is going from SRT to WebVTT, where it isn't enough to just add "WEBVTT FILE". I don't think we should keep trying stay closely compatible with SRT. Doing that means that we have less room to improve the timing line format, add comment syntax, etc.

While making it hard for authors isn't exactly a design goal, there's something to be said for "encouraging" people to use converters which will also help catch non-UTF-8 files, fix timestamps with less than 3 decimals, etc.

Also, since we're no longer trying to write a spec that can also be used to parse legacy SRT, syntax differences increases the likelihood that people will write a new parser matching the spec rather than tweaking an existing SRT parser to handle both formats, inevitably incorrectly.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see foolip's comments

mass-move component to LC1