Re: Unicode normalization in CSS

On Wed, 22 Jun 2011 03:22:12 +0200, Martin J. Dürst  
<duerst@it.aoyama.ac.jp> wrote:
> On 2011/06/22 5:24, L. David Baron wrote:
>> On Tuesday 2011-06-21 11:44 -0700, Phillips, Addison wrote:
>> I am *much* more concerned about the performance of normalizing
>> during selector matching than before parsing.  I think it's highly
>> likely that normalizing during selector matching would be an
>> unacceptable performance hit.  But I'd need to measure how bad
>> normalizing immediately after encoding conversion would be.
>
> Just so that you don't misunderstand me, I'm not advocating  
> normalization on matching. But I'd like to point out that you can ease a  
> performance bottleneck by pre-normalizing the identifiers that take  
> place in matching and keeping this pre-normalized form along with the  
> original form. If you want to make things even faster (completly  
> independent of normalization), you can intern (i.e. convert them into an  
> integer that is the same if the identifier is the same; often done in  
> Lisp or Ruby (:symbol)) each of the identifiers for fast comparison.  
> There are limits for this when it comes to selectors that match  
> free-form text, but I don't think such selectors are all too  
> popular/useful in CSS.

Without actual research that demonstrates this is a problem authors are  
actually facing I would not want to impose these requirements at all. It  
really complicates matters a lot and the benefit seems marginal. Even if  
one in hundred thousand authors has encountered this problem once it still  
seems questionable whether the right approach is to address this there.  
Everything done with JavaScript or on the server would have similar issues.

It seems much better to fight for normalization checking in validators and  
encourage editors to use a single mode: NFC.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 22 June 2011 08:36:06 UTC