Why CSS Needs No Variables

Published on April 1, 2009 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

This post is partially outdated.

(No, this is not an April Fools’ joke.)

CSS variables and constants are one of the top features web developers are asking for in web development fora, magazines, blogs, and on W3C’s www-style. Following a concept written by Daniel Glazman and Apple’s Dave Hyatt, the WebKit rendering engine even temporarily included support for variables. And in the meantime, others went for pragmatic solutions and used PHP to make variables work (by that suggesting that variables might not be needed in CSS).

Listening to web developer demands is a good thing. Yet there’s something odd about CSS variables, and a few CSS connoisseurs like Bert Bos shared some of their concerns in public. I’m not convinced about CSS variables, either, yet my objections are based on an emphasis on CSS coding style, including the idea of “using every declaration just once” which I explained under the hood of performance considerations: Declaration-based sorting cannot just reduce file size, it can also make style sheets more maintainable, to the extent that there is no need for variables, either.

Comparing CSS Variables and Declaration-Based Sorting

Before I illustrate my case against CSS variables from this coding style perspective please note that I’m not going for a detailed case study that compares a number of different styles. Instead I have to ask to accept the aforementioned style; I’ll use it as a reference until I get to write more about all of this.

I’ll now use a simplified style sheet, apply both Daniel’s and Dave’s variables suggestion as well as the “every declaration just once” method, and comment. The file size data are merely added for the impression of completeness.

#selector1 { color: black; }
#selector2 { color: black; }
#selector3 { color: black; }
#selector4 { background: black; }
#selector5 { background: black; }
#selector6 { background: black; }

The above is a sample style sheet (188 bytes) that ignores other things in a typical style sheet but features recurring property values that make variables so attractive.

Using CSS variables alters that sample to the following:

@variables { elementcolor: black; }
#selector1 { color: var(elementcolor); }
#selector2 { color: var(elementcolor); }
#selector3 { color: var(elementcolor); }
#selector4 { background: var(elementcolor); }
#selector5 { background: var(elementcolor); }
#selector6 { background: var(elementcolor); }

This style sheet weighs 296 bytes (108 bytes or about 57% bigger than the original) but, imagining a huge, complex style sheet, one might find it a bit easier to maintain.

In comparison, using every declaration just once, which should mean nearly the same maintenance implications as variables, gives us:

#selector1, #selector2, #selector3 { color: black; }
#selector4, #selector5, #selector6 { background: black; }

This freshly sorted style sheet weighs 110 bytes (78 bytes smaller than the original).

I said that I’d just go for applying two techniques (variables and declaration sorting), but let’s see how combining both approaches would look like:

@variables { elementcolor: black; }
#selector1, #selector2, #selector3 { color: var(elementcolor); }
#selector4, #selector5, #selector6 { background: var(elementcolor); }

This combined version is 170 bytes big (18 bytes smaller than the original sample).

Early Final Words

I know this day would be so much sunnier if I’d do more than just throwing code styles and numbers around, yet there’s a point in this. The main point is to see declaration-based sorting as a method not only to reduce file size and improve performance (as I presented it originally), but to use selector grouping to make style sheets more maintainable without needing to resort to variables.

Handing over to Bert again:

For many people, style sheets with constants will thus simply not be usable. It is too difficult to look in two places at once, the place where a value is used and the place where it is defined, if you don’t know why the rule is split in this way. Many people are confused by indirection anyway and adding an extra one, in addition to the element and class names, has the same effect as obfuscating the style sheet.

The next time we talk about variables we’ll hopefully discuss CSS Selector Variables instead. If I ever manage to follow up on those.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

On April 1, 2009, 9:24 CEST, Harry Roberts said:
Great post. I also think that adding in variables is introducing a complexity beyond the scope of CSS, a styling language, not a programming one.
And presuming that by changing the variable value once, all dependent declarations will adopt it’s (background)colour*, thus effectively changing all declarations that use the variable. Wouldn’t it therefore be just as simple to do a find/replace? Both achieve a mass changing of declarations, the latter is more true to CSS.
*to carry on your analogy.
On April 1, 2009, 9:26 CEST, Micheil Smith said:
I’m actually one who’s fully opposed to having css variables, because not only would they require extra overhead processing, be non-backwards compatible and add extra page weight, I see no benefit of using them.

Sure, if you’re making an el-cheapo website template, then they might have advantages, but otherwise, I don’t see the good points of them.

Surely the ones that can write good well versed css, will be able to manage their colours properly throughout a css document or multiple. I don’t really think that a CSS Colour TOC is necessary, but that’s a personal thing.

So, anyone know why anyone would want CSS Variables?
On April 1, 2009, 10:00 CEST, Samer Ziadeh said:
lol just earlier I was thinking why CSS doesn’t have vriables
On April 1, 2009, 10:14 CEST, Dave Woods said:
Hi Jens, I’m not really either for or against CSS variables so this comment is biased in either way. However, assuming that you also had some layout and other unique styling to apply to your example code then doesn’t Bert’s quote also apply to your method?

It is too difficult to look in two places at once, the place where a value is used and the place where it is defined

I’d much rather be able to set a colour theme at the beginning of a document and then reuse them wherever required

Example:
```
@variables { elementcolor: black; }
#selector1 {
color: var(elementcolor);
float: left;
width: 500px;
}
```
This could also be applied to things like common widths so changing from a fixed to relative width layout (as long as it was coded well) would be as simple as tweaking a couple of variables.

I’m not sure whether this method is a good solution but in my opinion is easier to read, understand and is much more scalable than the example in this article.
On April 1, 2009, 10:17 CEST, Robert said:
Aside:

“The above is a sample style sheet (188 bits)…”, although only assumed as a collateral information for the reader, leaves me wondering about the compression algorithm used to achieve this measure.

Gzipping the declarations from the first example renders 90 bytes transmitting a net payload of 188 bytes - won’t fit…

Am I April-fooled, thinking around in circles, or is [the quality initiative] applyable?

Please advise.
On April 1, 2009, 10:36 CEST, Jan-Christoph Borchardt said:
Sure, if you use such a small style sheet and a long variable name like »elementcolor«, it worsens performance.

But CSS, apart from being the tool to separate style from structure, made applying a style to every element redundant and uses classes (or elements itself) as variables to style several elements at once. Therefore, I think of CSS variables as the proper evolution. You can quickly affect many elements by only changing one property.
On April 1, 2009, 12:53 CEST, Kroc Camen said:
```
@variables { sirlancelotsfavouritecolour: blue; }
```
Sometimes the tools have to be provided, even if many people won’t know how to use them properly. Certainly, they should be a last resort, but in the right creative hands they may be able to help greatly (think Firefox’s XUL skinning). I don’t think they should be written out entirely, just that better examples and guidelines should be provided in the spec for proper use (just like the HTML5 spec warns against using tables for layout)
On April 1, 2009, 15:10 CEST, Daniel Glazman said:
Jens, with all due respect, you’re far here, very far from the expressed needs of Web authors. Maintaining an harmony of foreground and background colors in a set of stylesheets is such a pain that corporate stylesheet editors have asked for variables in CSS for more than ten years. Speaking of performance or bandwidth, there is nothing new here. A lot of people don’t know how to write good and efficient stylesheets, that’s all.

The key point here is not having all similar style declarations grouped, but having all repeated values declared in a central and trivially found place. It’s a matter of maintainability, and maintainability is often a compromise between purity and pragmastism.
On April 1, 2009, 15:37 CEST, Dirk Jesse said:
I don’t agree with your arguments. Your examples show exactly one thing: That there is no need for CSS variables if there are no other - more important - criterias (e.g. for maintenance) to group/sort various CSS selectors. But this can hardly be a tough argument against CSS variables.

The wish of CSS variables comes up when designing complex CSS layouts, so a counterexample using the most simple codebase doen’t make sense here. Take a look at Nicole Sullivans approach on what she calls “object orientated CSS“. She uses CSS classes to group elements and style them upon their meaning and to create reusable design patterns for huge websites. But this has a drawback as this leads to more markup because classnames have to be written into HTML and - as you say by yourself - this may raise maintenance costs.

So, in the case of complex layouts and user interfaces, CSS variables could be very helpfull and a reasonable option to follow the concept of “using every declaration just once”, whenever a simple selector sorting doesn’t fit to the needs of the recent project.

So, why do you think, offering one more options to the designer is a bad thing?
On April 1, 2009, 16:09 CEST, deryk said:
CSS should have included variables from day 1. I have read the arguments against CSS variables, and they all have to do with conforming to a certain CSS style that does not require variables. Well what about the rest of us who use a different style? Are we ‘wrong’ for coding in a different way. I think not. CSS should allow variables to allow for different styles.
On April 1, 2009, 18:06 CEST, Roberto Bonvallet said:
s/bits/bytes/
On April 2, 2009, 13:09 CEST, Jens Oliver Meiert said:
Harry, right, “search and replace” is also an option 😊

Micheil, thanks! I think later on the thread there are some proponents of variables voicing their point of view.

Dave, not sure, I think this method (of using every declaration just once) is different in that regard, so one doesn’t have to focus on several places (variable definition, variable use).

Robert, the examples are not gzipped, and I basically just took the “net weight,” for which bits was indeed the wrong unit, it’s bytes. (Of course, regular error report rules apply.)

Jan-Christoph, don’t pay too much attention to the bytes listed. I’m not sure I understand your reasoning in the second paragraph though, please elaborate.

Kroc, I understand you to mean that variables could be a reasonable addition, if used appropriately, is that right? (Always agree to the latter 😊)

Daniel, I know these “expressed needs of Web authors,” not just from the monthly suggestion to www-style 😉 I agree to the points Bert made though, and I also think that code style is one of the decisive factors for both CSS maintainability and performance (even though that is the very short story).

Dirk, good to see you here; sorry for being unclear. I think for the points you mention, Bert’s article might be less confusing.

Deryk, dto., I think Bert already writes about that in some detail. As the PHP implementations demonstrate, you don’t necessarily need CSS to create variables.

Roberto, that’s finally been corrected, thanks.
On April 3, 2009, 18:38 CEST, Jethro Larson said:
I use a css technique that follows the structure of the page(s) that it applies to. It’s pretty easy to follow even without comments. However in the persuit of fewer declairations the stylesheet can get ridiculously jumbled, and that makes the structure harder to read and maintain.

I would actually like to see property groups or something like that where you can specify a group of properties that you can apply to another selector. Think about it like adding classes without having to edit markup. Comma-separating your selectors is a way to do this but it can get ugly fast. For example I use declaration grouping for clearfixing boxes, that way I don’t have to add class=’clearfix’ to everything. However with large and involved website the list of clearfixed selectors gets to be 20 or more, and since that stuff is all grouped together it has to be pretty far away from the related rules. So declaration grouping is a good technique now but in larger applications just turns your stylesheets into spaghetti-coded messes.

Adding a couple ways to abstract some of the repetition out, will have a greater impact on code cleanliness and maintenance than trying to change the way people work.
On April 5, 2009, 9:23 CEST, Brian said:
thanks for the great post..
On April 5, 2009, 12:09 CEST, blacmox said:
Jens, please let me note that your comparision lacks objectivity; replacing a 5-character-string by a 12-character-variable produces a bigger file obviously. One can’t query the whole procedure by that.
I agree with you regarding css variables. Imo stylesheets aren’t responsible to alter markup dynamically. However you might give a break to css constants if you see the chances. Recently i wrote an article about the topic: CSS constants - variable values in CSS using PHP. Using constants / variables doesn’t imply to write unreadable code as you insinuate; it’s rather an option to make things easier.

I’m afraid i can’t see the point in Bert’s essay concerning PHP. So almost every technique lets the author determine the usefulness of it’s provided method. Furthermore it seems to me a bare argument that PHP can do what CSS could.

It’s nice, though that serverside preprocessing of stylesheets gives an answer to the demands of authors; until CSS gains more versatility i’m lucky to share a smart tool .-

Cheers, Sören
On April 6, 2009, 7:37 CEST, Jan-Christoph Borchardt said:
Jens, pardon my vague phrasing. I meant that CSS separated from HTML evolves in the concept of values separated from CSS. Classes are nothing more than variables.

Imagine there is no separated CSS with classes but you rather have to use inline styling in each and every corresponding HTML tag. That’s what CSS without variables feels like. Specifying a value after every property – and if something changes you have to plow through the entire code.

(yes, I know, search and replace is an option – a very cumbersome one)
On April 7, 2009, 12:19 CEST, Peter Gasston said:
Jens, I think you have a fair point in your article, but used an unfair example to illustrate it; using your logic, I could for example reformat the code as such:

@variables { elementcolor: black; } #selector1, #selector2, #selector3 { color: var(elementcolor); } #selector4, #selector5, #selector6 { background: var(elementcolor); }

But of course, variables would be used for much more than that; they could be used to store dimensions, and used in conjunction with calc() for easy layout, for example.
On April 7, 2009, 14:16 CEST, Rimantas said:
Well, your post only proves that for 6 lines CSS file you don’t need variables.
Otherwise, I am not convinced.
You usually don’t have only colors in your CSS, you have other properties, and for different element, event with the same color those properties differ.
With grouped selectors you will have to maintain separate list for each color, that adds size, complexity and can be very tiresome to maintain.
If you tend to avoid ids and classes you may employ descendent selectors to style your elements, putting that into grouped selectors list creates even more headache.
On April 7, 2009, 15:22 CEST, Kaelig said:
CSS Cacheer & CSS Scaffold enable the use of variables, nested selectors, classes as constants… AND it optimizes your css too (tidy + gzip). It makes your CSS highly maintainable.

Try them and you will see variables are a huge step forward.
On April 9, 2009, 3:58 CEST, Gastón said:
CSS variables is not bad, in fact is a good idea, the internet conections are faster every day, some bits is not so bad.
Best should think on the posibilities that give.
On April 9, 2009, 21:25 CEST, Thomas | Santhos Webdesign said:
I believe this could be great but I wonder if performance would be the main reason for this. We’re talking about bytes…. Would it really matter nowadays loading a 150 or 350 bytes css file?
On April 12, 2009, 18:07 CEST, Pat Denny said:
As I see it, variables could be used for more than just colors. They could be used for sizes, background images, positions. or customo font stacks. All sorts of things.

I’ve worked on several sites that need different color schemes for different sub-sections of the site (look at Slashdot as an example—not mine, but still an example)

the ability to simply overide the named variables and reuse the existing css in all these seperate sections would be far, far more efficient than redoing each sub-section’s CSS sheets, just to reintorduce thte color scheme.

The same can be said for different media types. One set of variables for print, one for screen (and mobile)… all of whom, then use the same master css afterwards.
On April 12, 2009, 18:53 CEST, Josef Go-Oco said:
Hmm. Relatively speaking, CSS vars are useless when applied to an example along the lines of what you gave. It would be priceless, to, say, a huge stylesheet. Rather than simple search/replace (which can affect unsuspecting values, mind you), variables are the way to go. This is useful if combined with numbers, most especially when basic arithmetic operations are possible. Now it’s easier to compute for relative lengths that rely on one another.

Also, I think the current syntax of variable calls is too verbose for its own purpose. It could just probably stick to $var or $(var).

Of course, given your example, it would be better to give people a choice between turning on the variables feature or not, as to save parsing time. Thus the key is knowing when not to use variables for optimum performance.
On April 12, 2009, 20:43 CEST, JasonG01 said:
I agree we’d be better off using php than any built in system. The nice thing about CSS is how clean and straightforward the code is, there’s no reason to clutter it.
On April 13, 2009, 0:47 CEST, Derryl said:
I agree with this statement.

“adding in variables is introducing a complexity beyond the scope of CSS, a styling language, not a programming one.”

I think the “developers” clamoring for CSS variables are just hardcore web programmers who feel uneasy around a language that doesn’t conform to their typical notions about what a language is supposed to do.

Variables are unnecessary. CSS is just fine the way it is, structurally, although I’d like to see some other functionality added.
On April 30, 2009, 15:45 CEST, anon said:
Considering both fit inside a TCP packet, there is nothing wrong with either. You’re debating the size difference that is not negligible
On April 30, 2009, 17:12 CEST, AaronSieb said:
I have to agree that a more complex example would be nice. How would you style a CSS class that relied on several variable properties?

Such as:
The width must be the same as the left gutter.
The background color must be the secondary background color of the theme.
The text color must match the theme.
The height is unique to this class.

Would you break this up into four selectors (one for each variable property, plus another for any unique properties)?
On May 3, 2009, 10:39 CEST, Jens Oliver Meiert said:
Travel and training kept me from replying earlier—thank you for a nice, constructive debate.

Thomas, for a very small style sheet you might indeed not really benefit from any sorting scheme or efficiency measure. However, you will not always just deal with very small style sheets, so a consistent approach might be more useful. (Hope that makes sense.)

Aaron, I reckon, based on my experience, that you get very similar results.
On May 6, 2009, 10:23 CEST, Daniel said:
Hmm, i ask myself if the performance of the browser will increase with css variables. Let´s take a color as an example. With css variables the browser have to read the color once. Every time the variable will be used, the browser have this value in the cache. Without the variables the browser have to interpret every single color value with no chance using his cache.

In German.
Ok, nochmal auf Deutsch. Stelle mir gerade den folgenden Fall mit dem Beispiel eines Farbwertes vor. Wenn der Farbwert als Variable gespeichert ist, so liest der Browser diesen Wert einmalig ein. Jedesmal wenn dieser Wert nun benötigt wird, kann der Browser den Wert aus dem Cache holen.
Wenn der Browser keine Variablen einliest, so muss er doch jedesmal wenn ein Farbwert in CSS deklariert wird, diesen erneut einlesen und umsetzten. Nach meinem Verständniss müsste das doch fast performancelastiger sein.

Greets

On May 7, 2009, 15:08 CEST, AaronSieb said:

So, you would style my example like this (with ExampleClass being the class I described in my previous comments)?

.ExampleClass, #LeftGutter {width: 25px;}

.ExampleClass, .a, .bunch, .ofOther, .classes {background-color:Red;}

.ExampleClass, .a, .bunch, .ofOther, .classes  {color:Blue;}

.ExampleClass {height: 100px;}

On May 8, 2009, 10:33 CEST, Shahriat Hossain said:
I like css short-hand code thanks for sharing your knowledge .
On August 3, 2009, 16:12 CEST, Kevin said:
I agree that variables would be highly useful for relative lengths. It’s a bit frustrating that CSS doesn’t have that functionality. Why should we have to rely on PHP or ASP to style our sheets? We should be able to attach a separate sheet, and get a separate look without having to resort to PHP or ASP. CSS is almost there–but variables would make it easier.
On August 5, 2009, 13:27 CEST, Grant Czerepak said:
I have currently been working with a stylesheet from a very large application and stripping away the variability in to achieve a minimal style.

Over the course of doing this I began to realize how useful variables would be and how poor your example is.

Variables would make global changes easy and local changes consistent.

CSS at its heart is a variable language.

What CSS needs is a meta style sheet where you can declare your variables and their values which in turn would be applied to the CSS.
On September 10, 2009, 14:00 CEST, ChrisH said:
The irony is, as Grant Czerepak points out, CSS is essentially a variables based language.

What is “.align-left”? It’s a declaration that tells HTML how to position an element. As such, to HTML, it is a variable.

Every time you write a class or ID , you are writing a “variable” for HTML to use. Why shouldn’t CSS declare and use “variables” too?

However, “variables” is a bit misleading, because in coding, variables are often, well, variable. eg a=b*c

What folks really want in CSS is definitions of constants, as blacmox also suggests.

So, you might have a header file that defines colour constants:
```
CORPORATEBLUE    #7777FF
CORPORATERED      #FF7777
```
In use,it might look like:
```
body {
  background-color:CORPORATEBLUE;
  color:CORPORATERED;
}
```
or to be even clearer it could use a prefix, such as $:
```
body {
 background:$CORPORATEBLUE;
 color:$CORPORATERED;
}
```
(please ignore the fact these colours would look shocking together like this!)

Call ‘em variables or constants, but I’m all in favour of them.
On September 13, 2009, 14:28 CEST, Eliara said:
I dont think variables in CSS will help much. First, you have to learn to make css/html very well, and if you do it best, you see, there are not that many colors or other properties to define. If you set for example to a{color:#fc0}, this color is for all the website links, where you need there variables ? And also for another selectors. I think, as there u can already define selectors, classes/id, it is already kind of variables!
On October 6, 2009, 18:53 CEST, Nils said:
Fail!
On December 14, 2009, 15:57 CET, Jean said:
I have read all comments and I could not find a single compelling argument against variables.

Grouping attributes by selectors can be good in some cases (i.e. because there are no variables in CSS), but obliges the designer to ungroup attributes pertaining to the same entities (e.g. classes), breaking encapsulation at the cost of maintainability.

Having variables in the CSS language would not force anyone to use them.

Optimization is a designer choice, should not be constrained by the language.

Using server-side scripting, or javascripting to provide CSS files on the fly is more difficult to maintain, and also inefficient, only somewhere else.

Maintainability is, for many, more important than bytes and it is far from proven than variables would increase CSS file sizes. It all depends on variables’ size and in the end, the choice of good variable names is a question of maintainability, not bytes.

Named colors (e.g. orange) are constants (second class variables), only not definable by the designer. Would you advise to remove them from CSS to save a few bytes for some who don’t use them?

That said I believe that variables are not enough for CSS. CSS ought to be a first class language just like every other language.

CSS is the language for styling, it needs objects, variables, expressions, etc.. The only constraint is that CSS should remain a style-description-oriented language. One should be able to write things like:
```
{
   color: body.background.complement;
   color: .corporateColors.foreground;
   border-width: $content.border_width;
}
```
On January 25, 2010, 23:50 CET, Rick Herrick said:
My primary need for variables in CSS is to resolve paths to included files, e.g. graphics. So if I have something like:
```
#myDiv {
   background:url("images/graphic.png");
}
```
What does that mean? You may be able to resolve this with relative paths, but that can fail when that path is moved. At that point the CSS relies on knowledge of something external to it and that’s what the variable (or really external property) is useful for. Then you can do something like:
```
#myDiv {
   background:url("${images}graphic.png");
}
```
On March 10, 2010, 20:02 CET, mawrya said:
After reading through all the comments, and the Bert Bos essay, I too can’t see a really compelling argument not to implement user-defined constants. I understand the arguments against, I just don’t find them very compelling.

As other comments have pointed out, the example given here is poor. For starters, using an alternate syntax the variable version could easily be rewritten to be smaller than the non-variable version.

Lastly, Dave Woods’ comment made a very good point. Related to it: this business of looking in two places at once is a non-issue if you gave your constants decent names. And with all your constants declared at the start of the file, it’s not like you would have to hunt for them. A good CSS text editor would provide mouse-over values for constants anyhow, much like Komodo does with it’s colour swatches.

CSS doesn’t need constants/variables, but it would sure make some tasks simpler.
On July 7, 2010, 21:16 CEST, Bugsy said:
My complaint comes down to a little practical use and math.

In your example you mention that your file is 57% larger, that’s true given the bytes.

However, there aren’t going to be stylesheets where every single selector has a variable associated with it, not to mention every property. There will be margins, fonts, all sorts of things.

For example, on this page your style sheet uses the property “color:” 9 times between 141 lines of code. That’s a much more realistic example than using a variable 7 times in 7 lines of code.

For example, by replacing all of the “color:” properties with a variable in your stylesheets increases the file size from 6153 to 6,333 bytes.

A difference of only 1.03% increase in bytes in a more realistic example and not 57%.

P.S. I am for CSS variables. But am quite content with how it all works now 😊
On December 7, 2010, 23:34 CET, CraigA said:
Agree with ChrisH, css should support constants. Its painful to use hex codes for theme colors scattered throughout a style sheet. Difficult to read and maintain.
On June 23, 2011, 14:00 CEST, Ray Bellis said:
I’d love to have some sort of ‘constant’ support.

If I want to make my own style declarations that use the same colours as my jQueryUI CSS from Themeroller I currently have no choice but to copy the values.

That’s a maintenance nightmare if I want to change the master theme (or use dynamic themes).
On July 15, 2011, 15:19 CEST, webton said:
Thanx, but I dont think variables in CSS will help much. First, you have to learn to make css/html very well, and if you do it best, you see, there are not that many colors or other properties to define.
On July 21, 2011, 17:52 CEST, Yesman said:
…what are you talking about? CSS is an entire language of setting properties. There is nothing more to CSS than this. There is no way a skilled person could believe that “there are not that many colors or other properties to define”, when the truth is the exact opposite.

Variables will be very useful for having dynamic effects, and for having a universal theme or color scheme to a website, especially if you want to make this color scheme dynamic. There is no way to get around having to set border colors, text colors, background colors, and even image urls to have a matching theme without having to resort to either using variables or to duplicating your stylesheet and switching them out (which is a much less elegant solution, and certainly takes up more file space).
On July 26, 2011, 14:07 CEST, Robin Castlin said:
I agree with post #38. One of the reasons I want definitions is because you can then easily have a root variable for all your images, thus making it easier to move and/or copy your site.

And you can’t simply “find/replace” this either. Just because you use #000 at one place, that doesn’t mean that you want to change every #000 to a certain value.

Making the server generate code on every css request is something which shouldn’t be required.

And bytes do matter in some extend. But mostly only on really big sites. If you want to save your precious bytes then you mightaswell write css as:
.a{color:#FFF}b{background:#000}
Lesser bytes, but you sacrifise logic; which at most times is what you really need to preserve.
On January 4, 2012, 22:38 CET, Max said:
CSS may not have originally needed variables, but with the proliferation of browser-specific markup, I find myself doing a lot of copy-paste in situations like this:
```
#pos0{
	border-radius: 0px 0px 6px 6px;
	-moz-border-radius: 0px 0px 6px 6px;
	-webkit-border-radius: 0px 0px 6px 6px;
}
```
could become:
```
@variables {
  c0: 0px 0px 6px 0px;
}

#pos0{
	border-radius:  var(c0);
	-moz-border-radius: var(c0);
	-webkit-border-radius:  var(c0);
}
```
which means I only change the data in one place, instead of 3. Cascading does not help with this problem.
On January 16, 2012, 20:57 CET, Derija said:
I too code in your style. Less code = better code. But I found my limits in some things when it comes to dynamic heights and widths when using CSS3 transitions. Without transitions, code like the following works perfect. Respect that the code is kept minimal, prefixes have been left aside.
```
.box {
  max-height: 14px;
  transition: max-height 0.5s ease-out;
}
.box:hover {
  max-height: 150px;
}
```
Without the transition, the content is instantly shown and the box’s height is set to its content’s height and limited to 150px. Just what I want, except for the animation. This, however, does not work as good, because the text is shown before the animation has completed.

I assume there is always a way around such things. It would be way easier if transitions could possibly apply to height: auto;.
Note that this is just an example I recently stumbled upon. I wouldn’t even quite know how to achieve this transition with variables, but there indeed have been other situations where I could have used them.

A better example would probably be a multicolumn design taking in the entire viewport except for 5px.
Again, position: absolute; certainly does the trick, but makes it a lot more complicated. All I’d like to have variables for is for easy dynamic dimensions.

But regarding the specifications that pop up first when googling for CSS Variables, not even CSS variables could do this. So I more or less prefer to do it the hard way, maintaining the “styling language”, as one of my preposters called CSS.

To suffice my personal needs, I’d be already glad to have arithmetic operators and the possibility to access values of other CSS styled elements within an element to for example adjust one element’s dimensions to another or implement a little spacer between two columns without having to position: absolute; them. But I guess that again would make CSS unnecessarily heavy.

So, in fact, even though I can see some useful aspects of variables, they probably tempt a newbe to “learn the wrong coding”, the untraditional coding. I agree with you.
On February 3, 2012, 18:00 CET, Wayne Kilmer said:
And your reasoning is why web developers are not really programmers. Using a variable name to specify a color value (as used in your example) allows for much easier site maintenance and significantly facilitates changes (changing the value of ‘elementcolor’ in one location versus finding all the elements whose color is to be changed from ‘black’ to a new value). The size savings you mention are insignificant.
On March 22, 2012, 7:22 CET, Craig said:
Why CSS variables are wrong:

* CSS is supposed to be declarative
* You can burn those CPU cycles *before* you deploy with scripts so each and every client doesn’t have to do the same work over and over
* ~~[deleted]~~
* It’s backwards incompatible and there’s no good way to implement fallbacks
* Stop breaking CSS you fucking hipster!
* It’s useless - stop bloating CSS with features for moron site template users
On April 10, 2012, 21:46 CEST, Mike said:
Would CSS variables be helpful with gradients. I mean you practically need to write a separate CSS line of code for every browser and every version of every browser? Variables would be helpful when changing the gradient.
On August 30, 2012, 17:35 CEST, Stuart Wakefield said:
Object-oriented CSS a la Nichole Sullivan is great if you have a consistent design structure and / or access to customise the HTML.

Combining declarations is great to cut the amount of CSS required, it is difficult to work with it if you are manually writing like that on a large application.

CSS variables force the client / browser to do additional work to cater for us developers which will negatively impact performance, if you are not sure what I am talking about… Two words… IE expressions… Ok a bit extreme, but it becomes an additional step the client has to do to use the website and it is something we can already do perfectly well…

You can get maintainability, reuse and optimization by using intermediate tooling, like CSS preprocessors such as SASS and LESS. You can write maintainable code that reuses declarations and have that built into optimized CSS… Everybody wins!
On September 3, 2012, 23:05 CEST, Christian Longe said:
A perfect example for variables in css3:
```
@media screen and (max-width: 480px;){
  @variables{ width:470px; padding: 10px; }
}
@media screen and (max-width: 980px;){
  @variables{ width:920px; padding: 30px; }
}

.body { width: var(width); padding: var(padding); }
.content { padding: var(padding);
```
Lets say you had three @media queries rather than the two, a common number. You would save about 40 bytes. So two @media queries you break even, any more than that is 40 byte savings per @media query in this example.

Another example for byte savings:
```
@variables { imageurl: http://www.example.com/images/ }

.body { background-image: url(var(imageurl)bg.jpg); }
```
How many bytes did that save? Its actually more bytes as a single use, but if you multiply by 30 images, now your talking some savings. Just because many people would use variables improperly doesn’t mean that you couldn’t benefit from them if they were used properly.

CSS is requiring more and more redundant code as html is becoming more and more static, as it should be, and more and more devices are reading it.

Further, many of us stupid template users are working for clients who are on a budget. Reusable templates that are quick to modify make a cheaper solution for clients to have a website that looks unique and professional. Everyone should be able to afford a space online. The longer it takes to make something properly, the less likely it will be done properly.

I would gladly take the smallest amount of cpu hit to have the page download faster. In most cases its the internet speed not the computer speed that slows things down.

Its funny to consider “oh my computer has to do 20 more calculations per page load, it can only do 100,000 per second.” in contrast to “My internet connection is slow and the css file is 50kb instead of 25kb, that could easily take me a second to download.” Your talking milliseconds vs actual seconds, hilarious.