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

Re: Case Sensitivity in CSS [I18N-ACTION-171]

From: Richard Ishida <ishida@w3.org>
Date: Thu, 17 Jan 2013 13:19:18 +0000
Message-ID: <50F7FA56.1070106@w3.org>
To: John Daggett <jdaggett@mozilla.com>
CC: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>, WWW International <www-international@w3.org>
 > No one outside of those implementing browsers view selectors and CSS
 > as "separate technologies"!!  Selectors are a core piece of CSS to
 > most folks!

I very much agree. I think that people using CSS want a simple and 
consistent rule to follow. Given that we can't change what has already 
been done, I'm thinking along the following lines:

[1] Although the CSS specification allows for ACI (ascii 
case-insensitive matching) in some places to be backwards compatible 
with existing content, the spec should require that *the user* should 
henceforth work with CSS as if it were case-sensitive throughout.

This makes it simple to know what to do.  There is a single rule to 
remember: always use the same characters (with the same case, where 
appropriate) for things that need to match.

It removes the confusion of some things, like class names, matching case 
sensitively, and others, like predefined counter identifiers, not. This 
also takes care of the normalization issues, and avoids confusion of 
normalization and case folding. It avoids people speaking certain 
languages having to do things differently from others - and avoids 
problems for people working with content in those languages alongside 
others having to figure out that they need to be careful for those 
languages. It avoids the problems of the complex rules about what 
actually does make sense or not in case-folding German. It avoids issues 
related to Unicode case-folding changing over time.

It's just simple.

[2] However, as a separate point, it possibly could go further. If it's 
only the machines that have to worry about ACI in some areas, and if 
it's for backwards compatibility reasons, it may allow us to specify 
exactly which identifiers and syntax elements are ACI *as a closed 
list*. That is, if a new pre-defined and ASCII-only identifier for, say, 
counters is added in the future, is can also be handled as 
case-sensitive by implementations.  As long as users treat CSS as 
case-sensitive from a practical point of view, this won't cause a problem.


On 16/01/2013 10:46, John Daggett wrote:
> Tab Atkins wrote:
>>> I think you can have case sensitive user identifiers and still
>>> match existing keywords case insensitively.  I don't see that as
>>> being that confusing to authors.
>> I believe it would be confusing if "@counter-style foo {}" and
>> "@counter-style FOO {}" defined two different counter styles, but
>> "@counter-style square {}" and "@counter-style SQUARE {}" defined
>> the same counter style and overrode each other.
>> The same argument for confusion can be made for property names, if
>> "color" and "COLOR" are the same property, but "var-color" and
>> "var-COLOR" and "VAR-color" are all different property names.  The
>> latter also makes it harder to deal with the var() function, which
>> drops the var- prefix from the variable name - is the "var" part of
>> a custom property name CI, but the rest CS?  Is it only valid if you
>> write literally "var-", not "VAR-"?
> Both of these are examples that matter to testers but don't matter at
> all to most authors.  Being able to match keywords with a mixture of
> cases is convenient but I don't think matching *locally defined*
> identifiers with a mixture of cases is in any way an important use
> case.  Authors accustomed to script *already* need to be aware of the
> casing of variables in their script, why would they expect it to be
> different in their CSS?  And authors using user-defined variables and
> counter styles already know enough to be aware that casing rules are
> different.  "User defined values, class names and identifiers are
> always matched case sensitively in CSS" seems like a pretty consistent
> rule of thumb.
>>> The flip side is if you make counters match
>>> case insensitively, why don't class names match case insensitively?
>> I am okay with technically separate technologies such as Selectors
>> having different expectations and rules.
> No one outside of those implementing browsers view selectors and CSS
> as "separate technologies"!!  Selectors are a core piece of CSS to
> most folks!
> John

Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)

Received on Thursday, 17 January 2013 13:19:49 UTC

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