Forking from #970: JS.md talk about Unicode normalization.
A simple example from that document: my name "Jean-François Bastien" can be normalized two ways with
Ç ↔ C+◌̧
This is a nice gotcha in Unicode. While interfacing between JS and wasm it would be good to know what to expect from producers and consumers. We may choose not to normalize, but we should say so.
I see 4 ways in which we can discuss normalization in JS.md:
- Forbid / error / ignore non-normalized inputs.
- Automatically normalize wasm inputs, and compare the normalized JS values.
- Automatically normalize wasm inputs, and expect the user to call normalize.
- Not normalize anything.
If we choose 2. or 3. we should specify which form of normalization we expect (because of course there are multiple forms of normalization).
jfbastien
All 6 comments
1, 2, and 3 seems like a good source for esoteric bugs in JS engines.
I vote 4.
RyanLamansky
on 30 Jan 2017
I think the convertToJSString function Web.md#names already specifies 4. Seems fine to add clarifying text to say that no normalization occurs, though.
lukewagner
on 30 Jan 2017
Agreed with @lukewagner.
rossberg
on 31 Jan 2017
FWIW, CSS doesn't normalize at all either.
tabatkins
on 4 Feb 2017
Yeah, nothing in the web platform uses Unicode normalization, other than string.normalize() in JavaScript and IDNA in URLs. 4 is definitely what you want here.
annevk
on 30 Mar 2017
Sweet. I want to make sure we document these decisions, and it seems we've reached consensus. Closing.
jfbastien
on 30 Mar 2017
Related issues
konsoletyper
·
6Comments
badumt55
·
8Comments
frehberg
·
6Comments
artem-v-shamsutdinov
·
6Comments
mfateev
·
5Comments
Most helpful comment
I think the
convertToJSStringfunction Web.md#names already specifies 4. Seems fine to add clarifying text to say that no normalization occurs, though.