- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 6 Feb 2009 06:29:40 -0600
- To: Philip TAYLOR <Philip-and-LeKhanh@royal-tunbridge-wells.org>
- Cc: Anne van Kesteren <annevk@opera.com>, David Clarke <w3@dragonthoughts.co.uk>, Henri Sivonen <hsivonen@iki.fi>, public-i18n-core@w3.org, W3C Style List <www-style@w3.org>
On Fri, Feb 6, 2009 at 4:58 AM, Philip TAYLOR <Philip-and-LeKhanh@royal-tunbridge-wells.org> wrote: > Anne van Kesteren wrote: >> (Ignoring for the moment the enormous cost and pain of changing >> codepoint-equality-checks to canonical-equality-checks in widely >> deployed software and standards...) > > I cannot see any causal relationship between "widely deployed" > and "enormous cost"; the cost would surely be much the same > were there just a handful of users, would it not ? > > On the other hand, the number of parsers is small and finite; > how many input method editors are there for all the world's > natural languaqes, I wonder ? That is surely where the real > cost would lie, were we to adopt Henri's preferred solution. You don't need all the input editors in the world to coordinate perfectly; you only need the input editors that *you* use to work correctly, and you're fine. 1 is a much smaller and more finite number. ^_^ And, as noted by Anne, while the number of *parsers* is small and finite, the number of programs *interacting* with the parsed input is very large. To get any sort of consistency, you need them *all* to change accordingly. In essence, for any particular person, only one editor has to change to meet their needs. If you avoid normalizing on input, then a whole host of programs need to change in a consistent manner. In an editor, the performance cost of normalization is minimal, and any slowdown wouldn't be noticed by a user anyway. In a browser, the performance cost ends up being much higher, and would probably be noticed by a user.
Received on Friday, 6 February 2009 12:30:22 UTC