- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 23 Jan 2013 14:37:01 -0800
- To: www-style@w3.org, 'WWW International' <www-international@w3.org>
On 01/22/2013 08:52 PM, Glenn Adams wrote: > > The primary ones are: > > CSSStyleDeclaration.cssText > CSSStyleDeclaration.getPropertyValue() > CSSProperties2.{various} > > [... http://lists.w3.org/Archives/Public/www-style/2013Jan/0318.html ...] > > Although there are some minor differences between all of these three browsers, it is clear that counter names are not case > normalized but list style types are case normalized, at least for the purpose of returning the computed value. > > I can't say if the same case normalization is used when performing comparisons internally. So from this we can conclude that the CSSOM returns case-normalized values for case-insensitive keyword values. Whatever case handling we choose, this is what the CSSOM will spit out. Which means that an author must either a) always use the case-normalized form b) learn how our casing operations work whenever interacting with the CSSOM If we use ASCII case-normalization, then b) will be really weird for non-English identifiers... and will depend on the Unicode normalization form of the input file. >_< If we use Unicode case-folding, then we run into weird things like lowercase eszet folding to double small S, and probably other strangeness that the author has to predict. Given this, I'm leaning towards Richard Ishida's (?) suggestion that we leave user-defined idents as case-sensitive and just grandfather in any CSS-defined keywords as computing to their lowercase variants. This would mean that @counter-style DISC { ... } e { list-style-type: DISC; } turns into @counter-style disc { ... } e { list-style-type: disc; } in the CSSOM even though @counter-style FOO { .. } e { list-style-type: FOO; } retains its casing. But I think it's a lot saner for the author than adopting any form of forced case-folding. Case-folding, whether ASCII or Unicode, is fine for matching, but it gets really weird as a normalization form. Also, this solution is compatible with the existing handling of counters, namespace prefixes, animation names etc. that are already case-sensitive. We might be able to get away with case-normalizing counter names in the CSSOM, but I doubt this is true of animations. ~fantasai
Received on Wednesday, 23 January 2013 22:37:34 UTC