- From: Phillips, Addison <addison@amazon.com>
- Date: Mon, 2 Feb 2009 11:02:05 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "www-style@w3.org" <www-style@w3.org>
> Why have you come to the conclusion that it's impossible to > reconcile with the current state of software? > > In this thread, you have some browser makers telling you they'd > vastly prefer that approach to having to consult experts on Unicode > normalization for every API, every property getter, etc., to > determine what the correct behavior is. > > I think switching to early Uniform normalization is something that > could be done in a single browser release for each browser maker. Because browsers are NOT the primary creator of the content. Early uniform normalization refers to every process that creates an XML/HTML/CSS/etc etc. document. The browser reads those documents and must still deal with normalization issues. > > Having to go through every Web-exposed API and decide on the > correct > behavior with regards to normalization is an approach that will > likely take decades, rely on being serialized behind the judgment > of > a very small number of people, produce a long series of decisions > whose internal inconsistencies will break substantive use cases, > and > still interfere significantly with the worldwide usability of any > software built using generic mechanisms (since you're not going to > teach every Web developer testing string equality in Javascript > which cases should use normalized-equality and which cases use > strict-equality). > Normalization sensitive operations will still exist that require specifications to deal with them--or not. Addison
Received on Monday, 2 February 2009 19:02:57 UTC