If their response is 'why', then the blogger is completely right and the standards body has no clue how the technology that the standard prescribes is used. The 'why' is simple, even if we only look at colors: every stylesheet contains the same colorcode over and over again, because good design requires coherent use of colors. Now you could make a style class called 'green', but I don't think I should have to go into the reasons why you just do not ever bloody want that. A proper stylesheet is bound to repeat a colorcode. A second solution is generating your CSS, but then you need a new standard defining a proper way to tell your CSS generator which elements should have the same color, which pretty much ends up being CSS with variables.

If they, and Bos, have any clue about what they are doing, they should tell us how to solve this problem, instead if asking the inane question you put in their mouths. What Bos comes up with in his essay is basically 'search-and-replace' and other 'tooling'. Well, why don't we just drop variables in our programming languages as well? We can just 'search-and-replace', can't we?

Because your programming language is a programming language, and CSS isn't? There's no part of this feature that couldn't be accomplished using a CSS templating system. You might as well ask why HTML5 doesn't include all the features of Cheetah or Erb.

A CSS templating system, that is just CSS extended with the possibility of symbolic constants, adding an extra step to the build process. One implementation I've seen used is using ant to replace the constants by their values. It's not hard, but that's exactly the point: it's also simple for Microsoft, the Mozilla Foundation, the KDE project, Apple, etc. to implement. I agree you shouldn't start adding real variables whose value can change halfway the CSS, variable scoping or, god forbid, if-then constructs. That doesn't mean simple constants should also be ruled out. I think that's throwing out the baby with the bathwater.

I'm not sure I see why:

"adding another step to the build process"

is worse than

"permanently standardizing one group's notion of what variables should look like when less than 1% of all web applications use any form of CSS templates"

I don't have to agree with Bos that high-level stylesheets are a bad idea (I don't; I think they're a great idea) to agree with him that we shouldn't be inflicting them on everything that renders or interprets styled HTML.

And hey --- for what it's worth --- I can see how Bos didn't do his argument a big favor by writing an essay-length rant about why variables are a bad idea. I think he raises some good points. For instance, have these proposals really thought scoping through, and have we really thought about how this will impact authorship tools? But these aren't the reasons we shouldn't be in the business of standardizing the idea.

On the other hand, Matt's argument is just as wrongheaded. It is absolutely not the case that standards groups should be rushing to alleviate web developer pain. Like I said, if they took that approach, we'd be stuck with QuickSilver templates, baked permanently into the HTML standard.

It's a lot easier to implement this on the server side than to try to get compatibility between the various browsers (especially Internet Explorer). A server-side implementation is also compatible with older browsers, which is a concern that would prevent CSS variables from coming into common use for a long time.

It's not just about the effort for browser developers. It's also about the effort of getting all the browsers in use to be more-or-less compatible with the standard.