Re: [CSS21][css3-namespace][css3-page][css3-selectors][css3-content] Unicode Normalization

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.