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 15492 - <track> Normalization for setter of TextTrackCue.text is not defined
Summary: <track> Normalization for setter of TextTrackCue.text is not defined
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2012-01-10 12:47 UTC by contributor
Modified: 2012-07-18 18:48 UTC (History)
3 users (show)

See Also:


Description contributor 2012-01-10 12:47:47 UTC

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
Comment 1 Fredrik S 2012-01-10 12:54:51 UTC
In section, 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 ( 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" (
Comment 2 Ian 'Hixie' Hickson 2012-02-06 22:05:51 UTC
What do you mean by "normalization" here? Can you show an example?
Comment 3 Fredrik S 2012-02-07 07:49:14 UTC
I mean "normalization" as in what's defined in 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':


which when parsed via a track-file would give:


while through cue.text it would render:

Comment 4 Ian 'Hixie' Hickson 2012-04-25 18:49:47 UTC
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.