Are CSS variables the future?

Replies to This Discussion

Permalink Reply by Daniel Leuck on August 6, 2008 at 11:48pm

I think Bert is dead wrong. His arguments seem to boil down to "They make CSS too complicated and difficult to read". Huh? Nothing is harder to maintain or read than a CSS file with the same three colors repeated 20 times :-/

It would be very nice to have your colors and fonts declared in one place. DRY! You can handle some cases via inheritance and application of multiple classes to a single element, but it doesn't help when you want to use the same color for the foreground of one element and the background of another.

Permalink Reply by Scott Murphy on August 7, 2008 at 12:20am

Dan- I completely agree. Bert didn't convince me at all so I was wondering if I had missed something out of that essay. He says variables will also make the learning curve of CSS steeper because it makes it harder for a beginner to learn and reuse other people's work? I don't see how that outweighs the benefits of having more maintainable code.

Daniel Leuck said:

I think Bert is dead wrong. His arguments seem to boil down to "They make CSS too complicated and difficult to read". Huh? Nothing is harder to maintain or read than a CSS file with the same three colors repeated 20 times :-/

It would be very nice to have your colors and fonts declared in one place. DRY! You can handle some cases via inheritance and application of multiple classes to a single element, but it doesn't help when you want to use the same color for the foreground of one element and the background of another.

Permalink Reply by John on August 7, 2008 at 7:53am

I think variables would be a huge help. A lot of the mess of CSS could be rectified that way.

The problem is, Bert's point boils down to programmers vs non-programmers. To a non-programmer, understanding the abstractions involved in using variables and other programming techniques is more costly than the benefits gained in DRYing out your CSS. To this, I agree.

Think of CSS like a product you are managing. CSS has two customer segments with a wide disparity in skills/understanding. If you implement variables and other programming abstractions, you run a high risk of undermining your other customer segment.

Permalink Reply by Daniel Leuck on August 7, 2008 at 8:03am

The abstraction represented by CSS variables is basically the same one introduced in 6th grade algebra. Anyone that didn't make it that far should probably avoid hand writing CSS and handling sharp objects. :-)
John said:

I think variables would be a huge help. A lot of the mess of CSS could be rectified that way.

The problem is, Bert's point boils down to programmers vs non-programmers. To a non-programmer, understanding the abstractions involved in using variables and other programming techniques is more costly than the benefits gained in DRYing out your CSS. To this, I agree.

Think of CSS like a product you are managing. CSS has two customer segments with a wide disparity in skills/understanding. If you implement variables and other programming abstractions, you run a high risk of undermining your other customer segment.

Permalink Reply by Scott Murphy on August 7, 2008 at 8:43am

I like the 6th grade algebra analogy. Am I the PTA parent pushing the school to teach algebra in the 5th grade so that they can start learning more advanced things? Bert and W3C would almost be the school board trying keep the standards to every student's level?

To me, if people can spend hours trying to figure out a IE hack, I'm sure they can spend 15 minutes learning the concept of what a variable is.

Perhaps CSS variables are a thing of the distant future and before even talking about wide acceptance, there are many other issues regarding CSS standards (um...IE) to be resolved.

Daniel Leuck said:

The abstraction represented by CSS variables is basically the same one introduced in 6th grade algebra. Anyone that didn't make it that far should probably avoid hand writing CSS and handling sharp objects. :-)
John said:

I think variables would be a huge help. A lot of the mess of CSS could be rectified that way.

The problem is, Bert's point boils down to programmers vs non-programmers. To a non-programmer, understanding the abstractions involved in using variables and other programming techniques is more costly than the benefits gained in DRYing out your CSS. To this, I agree. Think of CSS like a product you are managing. CSS has two customer segments with a wide disparity in skills/understanding. If you implement variables and other programming abstractions, you run a high risk of undermining your other customer segment.

Permalink Reply by John on August 7, 2008 at 8:54am

In my experience, this underestimates how difficult (and painful) it is for most non-programmers to learn programming.

Business is not like school. In business if you force your customers to do things that are too hard, they simply stop buying or using your product. Free markets force companies to be sensitive to the skills, talents and desires of their customers.

Even if variables are 6th grade skills to you or you think it can be learned in 15 minutes, this is clearly not the case for the population at large (if it was, everyone would already know variables and this would not be an issue).

Permalink Reply by Daniel Leuck on August 7, 2008 at 9:07am

I understand what you are saying, but I guess I put simple variable substitution in the same category as mail merges where "variables" are replaced by items in a list. I know plenty of non-programmers that can manage a mail merge. More importantly, I think CSS passed this threshold in terms of complexity a long time ago, and the reluctance to add simple variables is rather arbitrary. There are other aspects of CSS such as positioning, relative units and media types that are far more complex. CSS already requires a reasonably technical designer, so the omission of a feature that makes things cleaner for this type of person doesn't make sense to me.

Language design decisions like this are, to some degree, subjective. There are obviously pros and cons to both approaches.
John said:

In my experience, this underestimates how difficult (and painful) it is for most non-programmers to learn programming.
Business is not like school. In business if you force your customers to do things that are too hard, they simply stop buying or using your product. Free markets force companies to be sensitive to the skills, talents and desires of their customers. Even if variables are 6th grade skills to you or you think it can be learned in 15 minutes, this is clearly not the case for the population at large (if it was, everyone would already know variables and this would not be an issue).

Permalink Reply by Scott Murphy on August 7, 2008 at 12:46pm

John - I can't say how difficult the concept of variables is for the average non-programmer so perhaps 15 minutes was a little extreme and the school analogy strangely simplified the issue.

I guess, viewing CSS as a product, if CSS variables did become available with cross browser compatibility, it won't be something mandatory and forced upon that would cause people to stop buying it but rather an optional feature that hopefully makes the product more appealing. Having the choice, there will always be people who take the time to learn and use the new feature while others won't.

John said:

In my experience, this underestimates how difficult (and painful) it is for mosthow non-programmers to learn programming.
Business is not like school. In business if you force your customers to do things that are too hard, they simply stop buying or using your product. Free markets force companies to be sensitive to the skills, talents and desires of their customers. Even if variables are 6th grade skills to you or you think it can be learned in 15 minutes, this is clearly not the case for the population at large (if it was, everyone would already know variables and this would not be an issue).

Permalink Reply by Chris Runnells on October 22, 2008 at 11:22am

I'm not sure it's really necessary to include variables in CSS. Having used CSS for 6 years now, I'm not sure how it would help me much. As the essay mentions, there are already options for using PHP to output your CSS, and drop in your variables there.

I don't think that programming belongs in CSS, as that isn't it's purpose. It's easy enough to declare a single attribute for multiple elements, whether it's background color or setting the margins.

I just fail to see how they're that useful, but I'm ready to be enlightened. :)

Permalink Reply by Daniel Leuck on October 23, 2008 at 2:26pm

Yes, but this isn't adequate in many situations. For example, when designing themes for a complex web application you often have a palette of colors that are used in different contexts such as the background of one component and the font color of another. Although CSS supports reuse of a color value for a particular attribute such as background, it doesn't support reuse of a color across different attribute types (ex. background and font color.) In a complex css the same color can appear on a dozen different attributes. Requiring the color to be continually redefined violates the DRY principle and generally makes life miserable for the person maintaining the styles. Although its possible to use a template mechanism on the server via PHP, JSP, etc. this is not portable across platforms and can incur an unnecessary and potentially substantial performance penalty.

Chris Runnells: I don't think that programming belongs in CSS, as that isn't it's purpose. It's easy enough to declare a single attribute for multiple elements, whether it's background color or setting the margins.

Permalink Reply by Chris Runnells on October 23, 2008 at 8:10pm

Hmm, I'm not convinced by your argument. Colors are only used in a few places (IE: border color, background color, and font color).

In an environment like you described, where you've got CSS for a large web application, it seems like the best idea would be to have a set of CSS that defines the structure of the design, but without any font or color information. Then you've got theme.css where you define colors, typography, background images, etc.

/* theme.css */
body, hr, th, #header h1, { background-color: blue; }
table, .border { border: 1px solid blue; }

There's no reason why you can't contain all "decoration" to a single CSS file, and leave the structure of the content in a single unchanged file.

Yes, DRY says you shouldn't repeat yourself, but I think setting up a single CSS file (or worse, multiple CSS files) where you've replaced all instances of a single color with a variable, you're not going to save yourself any time in the long run. Sure, you might have saved a few bytes of data, but is it really worth the extra effort?

I still feel that in the situation you described the addition of another style sheet would be the best solution, from a web designer perspective. I don't think it's against the idea of DRY, because you're not repeating yourself, you've just removed the decorative CSS from the layout CSS of your application which is what CSS is supposed to be used for.

Permalink Reply by Daniel Leuck on October 23, 2008 at 11:25pm

Chris Runnells: I'm not convinced by your argument. Colors are only used in a few places (IE: border color, background color, and font color).

Colors are used in more than a few places. Borders alone have four colors, one for each side. I am currently working on a web theme system for an SNS platform where many of the colors are used in five or six attribute types within a theme. Having done a lot of work on Java Swing Look and Feel implementations and Flex skins I can say with certainty that this is very common in full featured theme / LaF implementations.

In an environment like you described, where you've got CSS for a large web application, it seems like the best idea would be to have a set of CSS that defines the structure of the design, but without any font or color information. Then you've got theme.css where you define colors, typography, background images, etc.

Of course, but this in no way addresses the issue of CSS requiring values to be repeated if they are applied to different attribute types such as background and font color. We already use different style sheets for layout, color schemes, etc. This is an orthogonal concern.

body, hr, th, #header h1, { background-color: blue; }
table, .border { border: 1px solid blue; }

This is a contrived example because you rarely use default colors such as "blue" in a real world style sheet. Your blue is more likely to be something like rgb(5,12,247), repeated for your background-color and border.

There's no reason why you can't contain all "decoration" to a single CSS file, and leave the structure of the content in a single unchanged file.

Again, you are talking about the separation of structural and stylistic concerns which is important but completely orthogonal to the issue at hand.

Yes, DRY says you shouldn't repeat yourself, but I think setting up a single CSS file (or worse, multiple CSS files) where you've replaced all instances of a single color with a variable, you're not going to save yourself any time in the long run.

Untrue. If you are dealing with a system with dozens of themes, each containing multiple style sheets containing dozens of colors you are saving yourself a lot of time and more importantly, you are creating a more maintainable system.

Sure, you might have saved a few bytes of data, but is it really worth the extra effort?

Saving bytes is not the issue and yes, it is well worth the effort.