- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 29 Jan 2009 16:15:32 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- CC: public-i18n-core@w3.org, www-style@w3.org
L. David Baron wrote: > On Thursday 2009-01-29 13:27 -0800, fantasai wrote: >> Thanks for the tests and the report, Richard. Going from that, I think it >> makes sense to require /not/ Unicode-normalizing CSS. It may be a bit >> confusing indeed for people working in Vietnamese and other such languages, >> but on the other hand behavior across browsers is interoperable right now. >> If one browser started normalizing, then someone testing in that browser >> would not notice that the page is broken in other UAs. > > In what parts of CSS might you want unicode normalization to be > done? The only case I can think of is selector matching that > compares attribute values (or, in the future, text content). And > even then it seems like it might be helpful in some cases and > harmful in others. > > (I tend to think we probably don't want it for selectors, both since > we currently have interoperability, and since selectors are > particularly performance-sensitive.) We do normalization-sensitive string matching in the following cases: selectors page names counter names namespace prefixes ~fantasai
Received on Friday, 30 January 2009 00:16:15 UTC