This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12043 - <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
Summary: <video> For better compatibility with .SRT, could the FULL STOP be replaced w...
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-11 23:37 UTC by contributor
Modified: 2011-08-04 05:34 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-02-11 23:37:35 UTC
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
Comment 1 Thomas Sturm 2011-02-11 23:48:13 UTC
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!
Comment 2 Silvia Pfeiffer 2011-02-12 00:58:27 UTC
(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.
Comment 3 Ian 'Hixie' Hickson 2011-02-16 08:34:42 UTC
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 ",".
Comment 4 Philip J├Ągenstedt 2011-02-16 09:04:57 UTC
(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.
Comment 5 Philip J├Ągenstedt 2011-02-16 09:06:44 UTC
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.
Comment 6 Ian 'Hixie' Hickson 2011-06-02 23:46:04 UTC
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
Comment 7 Michael[tm] Smith 2011-08-04 05:34:51 UTC
mass-move component to LC1