There was a very very very long thread on Unicode normalization in CSS
back in January/February of 2009. IIRC the conclusion was that the
problem is much bigger than CSS, and I18n had some work yet to do to
figure it all out.
Is that a correct recollection?
Daniel Glazman has been collecting outstanding issues filed against
CSS Namespaces since we now have the implementations to move to PR,
and this was one of them. But I couldn't find any conclusions to the
discussion.
I think realistically we have two options here:
1. Nothing is normalized in CSS.
2. CSS-internal user-defined identifiers are normalized to NFC, i.e.
- counter names
- namespace prefixes
- etc.
We already make a distinction between user-defined and CSS-defined
names in that user-defined names are case-sensitive.
http://www.w3.org/blog/CSS/2007/12/12/case_sensitivity
Within #2 we could
- Normalize at "parse" time, i.e. before exposing such identifiers
to the CSSOM.
- In this case we need to decide whether unquoted font names are
also affected. Probably yes.
- Normalize at "match" time, i.e. store and expose the identifiers
unnormalized, but define that they represent the same thing.
The third option would be to normalize the whole CSS file, but from
the discussions about interactions with XML, HTML, the DOM, etc. this
did not seem feasible, at least not without a non-lossy normalization
scheme, which Unicode currently lacks (NFC having been hijacked by the
anti-compatibility-character crusades).
So I guess the question is, what's the right way forward here?
~fantasai