- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 26 Sep 2012 17:34:09 -0700
- To: www-style list <www-style@w3.org>
At the last F2F we discussed the issue of the case of user-defined identifiers. CSS-defined idents are all case-insensitive; however, they are also all within the ASCII range, so it's very trivial to define what that means. User-defined idents can contain all of Unicode, which potentially makes the problem much larger. Currently, we define that user-defined idents are case-sensitive, but that's not easily compatible with several things we're doing where user-defined idents mix with CSS-defined idents, or where something that was previous CSS-defined is reinterpreted into a user-defined one in the UA stylesheet. So, at the F2F we agreed to make user-defined idents case-insensitive, but deferred defining exactly what that means until we get some more research on what's necessary/possible. There are a few reasonable options: 1. ASCII case-insensitivity. This is the minimal change to be compatible with CSS-defined idents migrating to being user-defined. However, it's very limited - if you write an ident in a language other than English, you may very well run up against casing issues that should be "obvious" to solve. 2. Latin1 case-insenstivity. This allows case-insensitivity within all the "English-like" languages, so that, for example, an accented lowercase letter is equal to its uppercase version. 3. Unicode case-insensitivity. I'm not very familiar with the possibility-space here, but I'm told there are algorithms for doing case-folding in Unicode. We specifically need one that can *canonicalize* a string into a comparable form, so we can turn it into an atomic string and do fast comparisons later, rather than one that can only be used to compare two strings. jdaggett was supposed to look into option 3 and report back. John, any progress? This is a blocking issue for both Variables and Counter Styles. ~TJ
Received on Thursday, 27 September 2012 00:34:56 UTC