This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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).
What do you mean by "normalization" here? Can you show an example?
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"
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.