12043 2011-02-11 23:37:35 +0000 <video> For better compatibility with .SRT, could the FULL STOP be replaced with a COMMA? So instead of 00:00:00.000 it would be 00:00:00,000 2011-08-04 05:34:51 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other CLOSED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#webvtt-timestamp P3 normal --- 1 contributor ian ian mike philipj public-html-admin public-html-wg-issue-tracking silviapfeiffer1 thomas public-html-bugzilla oldest_to_newest 45410 0 contributor 2011-02-11 23:37:35 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Section: http://www.whatwg.org/specs/web-apps/current-work/#webvtt-timestamp Comment: For better compatibility with .SRT, could the FULL STOP be replaced with a COMMA? So instead of 00:00:00.000 it would be 00:00:00,000 Posted from: 63.85.151.70 45411 1 thomas 2011-02-11 23:48:13 +0000 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! 45430 2 silviapfeiffer1 2011-02-12 00:58:27 +0000 (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. 45662 3 ian 2011-02-16 08:34:42 +0000 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 ",". 45670 4 philipj 2011-02-16 09:04:57 +0000 (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. 45673 5 philipj 2011-02-16 09:06:44 +0000 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. 49096 6 ian 2011-06-02 23:46:04 +0000 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 53959 7 mike 2011-08-04 05:34:51 +0000 mass-move component to LC1