Re: Unicode normalization in CSS

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.

Regards,   Martin.

Received on Wednesday, 22 June 2011 01:23:06 UTC