httpwebwitch - 4:08 pm on Oct 10, 2008 (gmt 0)

vvv is right; all the things you could do with CSS variables are already possible using other methods. Preprocessing will let you rewrite your CSS with variables injected - you may just end up with all your CSS files being handled by a parser, maybe your CSS files will have querystrings.

Javascript has complete control over the styling of DOM elements, and if you're adept with Javascript there isn't much you can't accomplish. I have yet to find a CSS limitation that couldn't be fixed with JS, however complex or annoying.

But one could argue that preprocessing CSS is a "workaround" to a deficiency in the language.
Parable:
You can create a dynamic web application using nothing but flat-files and HTML. Millions of flat files saved to show every possible permutation of screen content... theoretically possible, and in my early days building for the web (the early 90s), that's how I did it. In my first few web applications, output wasn't generated by run-time scripts or relational databases; user interaction was passed with POST to a CGI that rewrote a flat file stored on the server. Just because something can be done using primitive tools doesn't mean newer gadgets like PHP, SQL, etc are silly enhancements.

I feel the same way about variables declared in a CSS file. They *would* be useful. Use them or don't use them - that's the developer's choice.

I take offense, as alt131 did, with the elitist tone of the essay. Arguing that it would make CSS "too complex" or "too difficult" is a condescending position. It's already possible to create horrible CSS, just as it's possible to create spaghetti code. People who use the feature properly well will benefit. People who use it stupidly will suffer. Every programming (or markup) language is a power tool - making it easier to make pixels dance on your screen in interesting and meaningful ways. A power tool. Like a chainsaw, it can be used well, or badly. Don't presume to remove tools from my belt to protect me from myself - I want my chainsaw, dammit!

The argument that search-and-replace is preferable to single-definition and variable reuse is not convicing. Do a search-and-replace through your CSS to replace "5px" with "7px" and you'll end up replacing things you didn't intend to. If I had declared a variable "column_padding", I could change that without suffering the pain of seeing all my margins and font sizes and positioning values quantized to the new value.

I vote on the side of implementing variables and scripting functionality in CSS. I'm used to declaring "parameters" in XSLT, and it's such a handy feature... you declare a variable in one place, or externally, or have it passed into the script, and it changes the output. Why is that so bad?

A little scripting in CSS would go a long, long, way.
For eg, it would be handy to be able to define the style of one element based on properties of another. For instance, let the height of one <div> always be the same as the height of another <div>. On pages where user interaction changes dimension properties, this ability would be a boon. One relatively simple rule in the CSS would replace significantly more complex scripting required in Javascript.

Doesn't the ":hover" pseudoclass already encroach on Javascript's territory? That's "mouseover", isn't it! Now imagine doing all your hover styling using onmouseover events in Javascript. Aaaaugh! See, ":hover" is a taste of how good CSS *could* be. Why stop there?

Another point: So, you won't be able to snoop into my CSS with Firebug to see what my font-size variable is, or (eek) you may have to scroll. Oh, boo hoo. Cry me another river.

I'll give credit to Bert Bos for creating a careful, thoughtful, well-argued essay. It was a good read. I just don't agree.