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