This has already been done by SASS (http://haml.hamptoncatlin.com/docs/sass).

Ex. In SASS

!main_width = 10

!unit1 = em

!unit2 = px

!bg_color = #a5f39e #main

:background-color = !bg_color

p

:background-color = !bg_color + #202020

:width = !main_width + !unit1

img.thumb

:width = (!main_width + 15) + !unit2

yields

#main {

background-color: #a5f39e; }

#main p {

background-color: #c5ffbe;

width: 10em; }

#main img.thumb { width: 25em; }

(Edit: Is there some way to format comments here on new.yc like there is on Reddit? I tried using both pre tags and indenting and neither worked…)

This requires you migrate your stylesheets to a totally new syntax, which isn't a great solution.

The makefile rule will leave behind a .css file even if there's errors. Compare to "cc -c foo.c" and the existance of foo.o on an error; we don't do "cc -c foo.c >foo.o".

Things like this can cause hard to find problems further down the line in a big system build; after the error the target file exists and is newer than the sources.

Either don't use shell re-direction or do "cmd foo foo.tmp && mv foo.tmp foo".

Or if they can modify the script so if there's an error a return code of nonzero is returned which can be checked by the makefile.

Don't know why anyone's modded you down. I was thinking that either the interpreter, e.g. ruby, or the script itself already returned a non-zero exit status and the makefile detected that. That doesn't cause make to remove the target.

$ make foo

false >foo

make: *** [foo] Error 1

$ make foo

make: `foo' is up to date.

$

I suppose they could do "cmd foo >bar || rm bar" instead of the mv I suggested. But that causes no bar to exist whereas the mv leaves the pre-build one behind.

This has never arisen so far (the code is so trivial that errors are rare), but it's a good point, so I just updated the post.

I suppose you could also make $(SOURCES) depend on $(GEN) to save having to remember the "make clean" sometimes. Speaking of clean, the ....out needs cleaning up too, e.g. "rm -f $(SOURCES:%=%.out)" perhaps (untested).

Don't like this design binding CSS stuff and application vars, I could use as alternative a function that gets a CSS++ and turns it into a CSS, so that the CSS remains self contained. Something like this:

@define companyred #ff5000

@define warningborder border: 1px red dotted

h1 {

color: @companyred;

} ....

So that the CSS file makes sense by itself.

The are a few problems with this approach. First, it takes more work. Second, it makes it harder to share values between CSS files. (Of course, you could add an @include statement to the "CSS++" language -- but that's starting to get pretty heavyweight.) Lastly, having yet another language is kinda unnecessary and confusing, as compared to just integrating ordinary Ruby expressions.

First: you did the work just one time, it's a 10 lines of code function :)

Second: I use only a CSS, and only a JS file, it takes a lot of sense because the client will cache them both the first time, so even without include it's ok most of the times.

Lastly: It's semantically not more complex than your. Just @define to define and @symbol to expand.

But of course it's just a point of view like many things in design. I wanted to share my view about this because I planned to write the interpreter for this stuff and write a blog entry. Thanks for your article I'm happy it makes sense for others to extend in some way the CSS in order to have some kind of symbols.

CSS gurus and standard fundamentalists will usually reply that with inheritance you should never need this kind of stuff, but they lies ;)

Ah, misunderstood you first time round. The problem with just doing symbol expansion is that you can't have values that depend on other values (like the "Width + 10" example in the post). For us, this has been a large part of the gain.

Perhaps it's possible to mix this two things to get something like:

ruby {

.... ruby code defining stuff ...

}

attrib: @stuff

Self contained, not a new language, able to define stuff relative to other stuff.

Good work Patrick

thanks honey

haha - good to know the auctomatic love lasts well into the morning

No wonder it's taking you so long, you're playing with CSS. :)

cool

if you're using rails there's also this:

http://blog.airbladesoftware.com/2006/12/11/cssdryer-dry-up-your-css

also, even if you are just using ruby, why not rake and erb instead of make and eval?