What are the advantages and disadvantages of CSS variables?

I'm faced with a business requirement that I believe may be solved by implementing 开发者_高级运维CSS variables.

Basically, while the front-end developers on this project are in charge of CSS implementation, the designer wants to be able to introduce different "themes" for the site.

By swapping one theme for another, a range of changes (such as font-size, font color, border width, etc) can be made without having to change too much code.

Currently we're trying to fit this requirement by splitting up the styling of components into different CSS files - e.g. one for layout, one for typography, one for colors, etc.

But I don't like this approach. It makes the CSS quite unmaintainable, and it's difficult to separate out all the CSS for one particular component, which is becoming a frequent requirement.

I'm hoping to instead introduce a standard set of "variables", which can be tied to a particular theme.

The CSS will be pre-processed and the variables will be swapped for the actual value depending on the theme used.

This will enable us developers to organize our code most effectively, while still keeping it flexible enough to be customized according to the designer's tastes.

Any thoughts on the pro's/con's of this?

The only disadvantage that I can think of is the added complexity of having to use or write a pre-processor, and appropriately manage the caching of the output in order not to have each request pass through the pre-processor.

You might also have some issues with syntax highlighting in editors when you use your new variable syntax, but that can probably could be solved.

Apart from that, I guess it should be all advantages.

You might be interested in checking out LESS:

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

Pre-processing a CSS seems like a good idea. The disadvantage I see is that, this additional abstraction will entail its own problems - bugs in the processing code might lead to an invalid or buggy CSS. Overtime things might become difficult to maintain.

You might want to have one fully working CSS without the variable, and then have another pre-processed CSS with the minimal required variable stuff, which overrides the original CSS.

I don't see any improvement over just having different css-files for the themes: You say you just add some variables to change fonts, colors and the like. What about borders, alignment and a lot of other stuff? Themes are not just 2-3 color variables. A theme for a bigger webpage can get pretty big and different themes for the same page might not only differ by a few colorcodes. I don't think it's a good idea. Let the front-end designers just create different css-files for the themes and load the css-files that belong to a theme.

A big disadvantage is certainly that you aren't writing CSS anymore. You are writing in a proprietary language, that compiles to CSS. Inventing your own programming language is on page one of the things-that-are-a-bad-idea-for-business book. If you are doing this as an experiment or for a personal project, then go ahead, but otherwise I'd say that you're asking for trouble.

A concrete problem I could foresee is that developers might have editors/IDE's that knows how to deal with CSS, but don't know how to deal with your dialect of CSS. That could restrict said developers quite a bit.

But really - The point isn't listing up pros and cons. The point is that you're moving into uncharted territory, and that's - out of principle - a bad idea, unless it's your core business.

Edit:

I'd just like to moderate my answer a bit. From a technical perspective, it may well be a good idea - Depending on how well you control your environment, how able you are to retrace your steps and a lot more. This is essentially a type of external-DSL, which can be a very powerful instrument. I don't think I would apply it here though, since you're targeting (frontend) developers, and I think external-DSL's are better used at administrators/non-developers. But it could be used successfully.

My main concern is that you're only approaching this from a technical point of view, which is a common fallacy for us developers. From a business-perspective (assuming you are a business), it's probably a really bad idea. That's what I was trying to voice.