More fun with CSS

I just spent an embarrassing amount of time wondering why my Web application wasn’t displaying things the way I thought it should. When in desperation I made a totally outrageous change to the stylesheet and the display didn’t change, I finally figured out the problem. In my stylesheet, the class name was newVidPreviewImg. In the JavaScript code, it was newvidPreviewImg.

Yes, I had a case problem. My mistake, true, and I’ll own it. But I’ll also say that making names case-sensitive is perhaps the dumbest design decision I’ve seen in CSS–a language that’s chock full of idiocy. The entire language, if you can call it that, is so full of exceptions, limitations, and inconsistencies that it’s pretty obvious the thing is the result of a failed design that was repeatedly patched to handle special cases rather than redesigned to make logical sense. It’s a kludge of the highest order.

Case sensitivity in file names or in programming language identifiers causes an incredible amount of confusion. Development environments that include features such as Intellisense lessen the impact, but don’t eliminate the problem completely. When you’re coding HTML, for example, and you write something like:

<div class="myCoolDivName">

There’s nothing that checks your CSS stylesheet to make sure that “myCoolDivName” is in fact defined. If the name is instead “myCoolDivname”, you’re in for a bit of confusion. The same kind of thing happens in JavaScript.

I’ve yet to see a good argument in favor of case sensitivity in identifiers. Certainly, a programmer would be foolish to define two identifiers in the same scope that differ only by case. It can only cause confusion and lost productivity, especially when you’re working with tools that can’t tell you that you’re making a mistake.

There are many programming language features that, over the years, have been found to be more trouble than they’re worth, and they’ve been eliminated or restricted. Modern languages, for example, restrict the use of the goto statement to prevent you from jumping into the middle of a function or a control structure (you can’t jump into the middle of a loop, for example). C# disallows the shorthand if (a = b) (combined assignment and conditional) because it’s entirely too easy to mistakenly type that construct when you really meant if (a == b) (simple conditional, without assignment).

Case sensitivity is one of those “features” that should not have been included in the C# language, and I suspect it would not have been if the designers weren’t concerned with making it easier to port existing C and C++ code. At least C, C++, and C# have the benefit of a compiler that will tell you when you’ve referenced an undefined identifier. Try working in JavaScript, where identifiers are defined on first use and they’re case-sensitive.

Case sensitivity: evil incarnate. I would suggest that you avoid it if at all possible. It can only hurt you.