15492 2012-01-10 12:47:47 +0000 <track> Normalization for setter of TextTrackCue.text is not defined 2012-07-18 18:48:59 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#dom-texttrackcue-text P3 normal Unsorted 1 contributor ian fs ian mike contributor oldest_to_newest 62467 0 contributor 2012-01-10 12:47:47 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#dom-texttrackcue-text Complete: http://www.whatwg.org/c#dom-texttrackcue-text Comment: Normalization for setter of TextTrackCue.text is not defined Posted from: 2001:4c28:a030:30:72f3:95ff:fe00:4501 User agent: Opera/9.80 (X11; Linux x86_64; U; sv) Presto/2.9.168 Version/11.51 62468 1 fs 2012-01-10 12:54:51 +0000 In section http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-texttrackcue, step 6 (specification for the TextTrackCue constructor) it said that: "Let cue's text track cue text be the value of the text argument, and let the rules for its interpretation be the WebVTT cue text parsing rules, ..." the referenced section of the WebVTT specification (http://dev.w3.org/html5/webvtt/#webvtt-cue-text-parsing-rules) does not define normalization. I would expect that cue text set using TextTrackCue.text or the TextTrackCue-constructor to have the same normalization rules applied as for a cue parsed via the WebVTT parser - i.e, basically step 1, "WebVTT parsing algorithm" (http://dev.w3.org/html5/webvtt/#parsing). 63776 2 ian 2012-02-06 22:05:51 +0000 What do you mean by "normalization" here? Can you show an example? 63811 3 fs 2012-02-07 07:49:14 +0000 I mean "normalization" as in what's defined in http://dev.w3.org/html5/webvtt/#webvtt-parser-algorithm step 1. I.e: '\0' -> U+fffd '\r\n' -> '\n' '\r' -> '\n' It occurred to me that it may be weird if one of the paths (the one through the VTT parser) had well-formed/normalized input while the other two (TextTrackCue.text and the TextTrackCue constructor) did not. The cue text tokenization/parsing algorithm itself will probably handle it, but the result will be different for the same input depending on the way it took through the parser. An example might be anything with an embedded '\0': <i>F\0oo</i> which when parsed via a track-file would give: <i> +-"F\xfffdoo" while through cue.text it would render: <i> +-"F\0oo" 67037 4 ian 2012-04-25 18:49:47 +0000 Ah, I see. The normalisation is defined, it's just that it's the null operation. We only "normalise" newlines in actual text files because they can often change from one style to another just from the file being opened and saved on a different platform, which might break scripts, and we only normalise nulls because they can be the source of unexpected truncation bugs in naïve software. These concerns don't really affect the DOM API, so there's not really any need to do them there. This is consistent with how HTML works in general.