views:

94

answers:

4

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?

+4  A: 

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;
}
Daniel Vassallo
+1  A: 

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.

tathagata
Good idea. I could maintain most of the current code-base as-is, but have write some of the new CSS using variables, as a kind of experiment.
jonathanconway
+1  A: 

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.

troelskn
@troelskn: You make a good point, but I wouldn't be that drastically against CSS pre-processing. It's quite popular, and there are plenty of mature and popular pre-processors around. [LESS](http://lesscss.org/) is one of them, for example.
Daniel Vassallo
Hmm, it turns out that that may not be the case ("Domain Specific Language" anyone?) although I do actually agree that in this case I'd probably tend to agree.
Murph
@daniel True. I assumed he meant to invent his own dialect. Even though, CSS is much more of a standard than lesscss, sass and whatnot and is. I still remember the outfall of the surge of template languages that were popular in the PHP world, some 5 years ago. Every friggin shop had a new template language that you had to learn.
troelskn
+1  A: 

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.

xor_eq
What you say is true. However, that still leaves me with the problem - how do I keep CSS clean and maintainable, when I might have 2 or more copies of everything floating around?How do I get around the fact that, when using the method you describe, a small change to one component could involve modifying many files.
jonathanconway