- From: <bugzilla@jessica.w3.org>
- Date: Sat, 12 Feb 2011 00:58:28 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12043
Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |silviapfeiffer1@gmail.com
--- Comment #2 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 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.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 12 February 2011 00:58:30 UTC