This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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
Lets also allow form feed characters then just like with HTML (the parser already parses them).
(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?
Come again?
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).
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.
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.
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).
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.
Ignore comment 10. That is bug 14572. My bad.
(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.