14487 2011-10-17 22:45:54 +0000 <track> accept more white space characters as cue timing separators 2012-07-18 18:39:27 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All CLOSED FIXED P2 normal Unsorted 1 silviapfeiffer1 ian annevk ian mike contributor oldest_to_newest 58308 0 silviapfeiffer1 2011-10-17 22:45:54 +0000 Right now http://www.whatwg.org/specs/web-apps/current-work/webvtt.html#webvtt-cue-timings only accepts the U+0020 SPACE character as a separator between "-->" and the timestamps. When authoring, the TAB character is often visually indistinguishable from the SPACE character. We could be more lenient towards hand-authored content if we allowed the TAB character as a separator, too. 58803 1 ian 2011-10-24 23:48:51 +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: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 58804 2 contributor 2011-10-24 23:49:13 +0000 Checked in as WHATWG revision r6741. Check-in comment: Allow tabs and multiple spaces between timestamps and the --> in WebVTT (it was already parsed that way anyway). http://html5.org/tools/web-apps-tracker?from=6740&to=6741 58820 3 annevk 2011-10-25 02:11:17 +0000 Lets also allow form feed characters then just like with HTML (the parser already parses them). 58822 4 silviapfeiffer1 2011-10-25 02:20:23 +0000 (In reply to comment #3) > Lets also allow form feed characters then just like with HTML (the parser > already parses them). As in: start time, --> and end time all on separate lines? 58823 5 ian 2011-10-25 02:25:53 +0000 Come again? 58826 6 annevk 2011-10-25 02:27:44 +0000 CR and LF are treated as newline separators by the parser. When collecting timings and settings data SPACE, TAB, and FF are treated as whitespace (it uses the definition "space characters" which is SPACE, TAB, FF, CR, and LF). 58850 7 ian 2011-10-25 04:25:40 +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: We discussed this on IRC, and decided that allowing form feeds wasn't a win. 58972 8 silviapfeiffer1 2011-10-26 03:56:14 +0000 A small note: the parser in the spec currently allows *0 or more* space or tab characters, not *1 or more* space or tab characters as specified in Ian's change. The WebKit implementation now enforces at least 1 space or tab character (so that [time]-->[time] without any spaces or tabs is not allowed). Clarification is requested. 59003 9 ian 2011-10-26 20:40:56 +0000 I don't understand. What is it you are suggesting change, and why? As far as I can tell, the spec is as intended (authors are required to give one or more space or tabs between the timestamp and the -->, but the parser accepts spaces, tabs, and form feeds and does silent error-correction if the spaces are omitted entirely). 59060 10 annevk 2011-10-27 09:29:24 +0000 The problem is with the parsing of settings. For values it e.g. collects characters that are not spaces, but then does not continue to collect characters that are spaces. I corrected this by before setting "setting" to the character at the current position (step 3 in the specification) collecting space characters and dropping them on the floor. 59070 11 annevk 2011-10-27 13:02:18 +0000 Ignore comment 10. That is bug 14572. My bad. 59192 12 silviapfeiffer1 2011-10-29 10:20:50 +0000 (In reply to comment #9) > I don't understand. What is it you are suggesting change, and why? As far as I > can tell, the spec is as intended (authors are required to give one or more > space or tabs between the timestamp and the -->, but the parser accepts spaces, > tabs, and form feeds and does silent error-correction if the spaces are omitted > entirely). I guess this works as long as we insist on 3 digits for the milliseconds. Resetting to RESOLVED-FIXED.