[webvtt] over-specification in Conformance: Unicode normalization (#483)

aphillips has just created a new issue for https://github.com/w3c/webvtt:

== over-specification in Conformance: Unicode normalization ==
Section: `Conformance: Unicode normalization`
https://www.w3.org/TR/webvtt/#unicode-normalization

> Implementations of this specification must not normalize Unicode text during processing.

>>For example, a cue with an identifier consisting of the characters U+0041 LATIN CAPITAL LETTER A followed by U+030A COMBINING RING ABOVE (a decomposed character sequence), or the character U+212B ANGSTROM SIGN (a compatibility character), will not match a selector targeting a cue with an ID consisting of the character U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE (a precomposed character).

The I18N WG noticed the above conformance requirement recently and discussed it in recent teleconferences. 

Unicode normalization is only one consideration that affects processing of WebVTT and its operations (such as the matching of cue identifiers). While this requirement is consistent with our recommendations and intentions, we'd suggest that you consider a more expansive approach as documented in our document Charmod-norm, particularly [section 3.1](https://www.w3.org/TR/charmod-norm/#choosingMatchingAlgorithm). Unless there is a special reason that our WG is unaware of, WebVTT is not especially sensitive to variations, so a case-sensitive non-normalizing matching for cue identifiers makes sense to us. 

The other concern we have is that this requirement forbids any and all normalization when processing a webvtt document, not just when performing operations such a cue id matching. Is there a reason to extend a processing requirement to the entire document? Or to forbid normalization when converting character encoding (although, if memory serves, webvtt doesn't support encodings other than UTF-8, so this may not apply)



Please view or discuss this issue at https://github.com/w3c/webvtt/issues/483 using your GitHub account

Received on Thursday, 23 April 2020 13:54:47 UTC