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.
"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.
Comments
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.