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 19465 - Parsing issue with --> in cue
Summary: Parsing issue with --> in cue
Status: RESOLVED WONTFIX
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-11 11:11 UTC by Cyril Concolato
Modified: 2012-10-13 05:15 UTC (History)
5 users (show)

See Also:


Attachments

Description Cyril Concolato 2012-10-11 11:11:37 UTC
Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=17558 describes that --> needs to be banned from the allowed syntax in cue data. However, when XML data is carried in metadata tracks, the XML comments end tag uses the sequence of characters -->. This should be acceptable to a parser, since metadata tracks don't use escapes.
Comment 1 Ian 'Hixie' Hickson 2012-10-11 17:28:03 UTC
We don't support XML comments or empty lines in cue payloads. Both cause the parser to assume the cue has ended.
Comment 2 Silvia Pfeiffer 2012-10-11 21:14:20 UTC
I can understand why we wouldn't want to support empty lines. But I think we could tolerate --> if we would only look for the next "-->" after the next empty line. The less restrictions we pose on cue text, the less broken files we will get.
Comment 3 Simon Pieters 2012-10-12 08:20:38 UTC
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14550
Comment 4 Simon Pieters 2012-10-12 08:21:40 UTC
Should we have different parsing rules for metadata tracks?
Comment 5 Ian 'Hixie' Hickson 2012-10-12 19:00:55 UTC
You don't know what's a metadata track when parsing. It would be crazy to take a WebVTT file linked to as a metadata cue file, switch it to be a caption file, and suddenly find you had different cues.
Comment 6 Silvia Pfeiffer 2012-10-13 05:15:10 UTC
If we make it dependent on the presence of a "Kind: metadata" marker in the header of the file, we could do that.