This is a page from the Cascading Style Sheets Working Group Blog. Some other places to find information are the “current work” page, the www-style mailing list, the Future of CSS syndicator, and the issue list on Github.
Do you want to know how the CSS WG works? Fantasai has written about:csswg, An Inside View of the CSS Working Group at W3C.
Case-insensitivity in CSS is currently not precisely defined. The meaning of “case-insensitive” is pretty obvious in ASCII, but it’s not so obvious in Unicode. Some characters map differently based on the locale, some characters can’t round-trip a case mapping operation so you get different matches depending on whether you map to lowercase, uppercase, or “case-fold” case, etc.
There was a recent discussion about this problem on www-style. Martin best summarized the problem and its constraints in his message on November 8th.
There are two issues here:
For the first issue, since CSS-defined identifiers only use characters
in the ASCII range anyway, ASCII case-insensitivity would be sufficient.
It would also prevent strings containing characters outside the ASCII
range from unexpectedly matching CSS keywords (which could cause
security problems).
For the second issue, we could adopt the Unicode case-folding algorithm,
which is at least well-defined. However a test shows that
implementations already treat counter names as case-sensitive. This is
interoperable across all four major CSS counters implementations:
Firefox, Opera, Safari, and PrinceXML (an HTML/XML + CSS -> PDF
converter).
Also because it’s much more straightforward than case-insensitivity in
Unicode, case-sensitivity is more likely to be interoperable going forward.
The downside is that case-sensitive counters could be more confusing for
authors used to case-insensitive CSS.
The CSS Working Group proposes to adopt the following changes:
These would
Unless there are objections that cause us to reconsider, we plan to
formally resolve this issue on 8 January 2008. Please send any comments
before then.