RE: Unicode normalization in CSS

> > Generally speaking, I agree. However, the likelihood of and
> > reasonableness of normalizing documents during the parsing stage is
> > under question. Normalizing documents on-load may interfere with the
> > user's intentions. Additionally, user-agents haven't imposed
> > normalization for reasons (realistic or imagined) of performance.
> 
> 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.
> 

Totally agree. Performance during matching is, of course, a critical operation. I'm not necessarily saying, btw, that normalization can't be done during the parse step. Only that it should probably be limited to identifiers used for selection. There are other ways that normalization might be acceptable---checking normalization is relatively fast and you might only have a slowdown in the (relatively unlikely) event of a denormalized string used as an identifier. Regardless of what other normalization steps we might recommend (or not), selection identifiers should have a strong normalization recommendation (for content/content authors) to ensure consistent operation. If doing normalization is rare, it might not matter as much.

Addison

Received on Tuesday, 21 June 2011 20:32:47 UTC