11647 2011-01-02 21:22:39 +0000 Use exactly 2 digits for hours in WebVTT timestamps 2011-08-04 05:35:56 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#parsing-0 P3 normal --- 1 contributor ian ian mike philipj public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 43763 0 contributor 2011-01-02 21:22:39 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html Section: http://www.whatwg.org/specs/web-apps/current-work/#parsing-0 Comment: Use exactly 2 digits for hours in WebVTT timestamps Posted from: 81.234.240.182 43764 1 philipj 2011-01-02 21:23:46 +0000 It seems to me that the parsing of WebVTT timestamps is more convoluted than it needs to be, and that the reason is that hours can be any number of digits. In SRT it is exactly 2 and I think just going with that would be simpler. Allowing an arbitrary number of digits just makes parsing more complex and forces implementors to handle overflow in timestamps like 99999999999999999999999999:00:00.000 and using greater precision than really necessary. There's also extra logic thrown in to not allow single-digit minutes in step 13.1. I'd prefer exactly 2 digits for hours, limiting WebVTT to use with video files of duration shorter than 100 hours, which is hardly a practical problem. 45097 2 ian 2011-02-03 21:06:57 +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: Don't forget that this stuff applies to infinitely streaming videos. I think it's perfectly reasonable to expect kiosks to be streaming videos for months at a time, let alone more than 4 days, and one can totally imagine that in such a scenario a script might be adding cues onto a video that is playing at a point longer than 100 hours. 54088 3 mike 2011-08-04 05:35:56 +0000 mass-move component to LC1