- From: Richard Ishida <ishida@w3.org>
- Date: Thu, 17 Jan 2013 13:19:18 +0000
- 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. RI 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) http://www.w3.org/International/ http://rishida.net/
Received on Thursday, 17 January 2013 13:19:49 UTC