- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 01 Feb 2009 11:13:07 -0500
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-i18n-core@w3.org, www-style@w3.org
Anne van Kesteren wrote: > 3. How likely is that XML will change to require doing NFC normalization > on input? Currently XML does reference Unicode Normalization > normatively, but it does only do so from a non-normative section on > guidelines for designing XML names. If XML does not change it does not > make a whole lot of sense to change e.g. CSS selector matching because > that would mean some XML element names that are not in NFC could no > longer be selected. It seems to me that the normalization proposal would involve normalizing both strings before matching, so they could still be matched. > The last one is quite important. If Unicode Normalization is so > important it has to happen everywhere, otherwise the platform becomes > inconsistent. Right. One question I have is whether this issue would be resolved if a UA performed parse-time normalization on everything (JS, CSS, XML, HTML). That wouldn't completely help JS because you can build up strings codepoint-by-codepoint but that also lets you create invalid UTF-16 strings, so I'm not sure it's worth worrying about right now. If the above parse-time normalization would not solve the issue, can someone explain to me why or point me to the relevant resources that would explain why? -Boris
Received on Sunday, 1 February 2009 16:14:09 UTC