W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Fwd: Case Sensitivity Issue and CSSOM

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 23 Jan 2013 14:37:01 -0800
Message-ID: <5100660D.2010601@inkedblade.net>
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.

Received on Wednesday, 23 January 2013 22:37:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:25 UTC