That’s why this is not a good idea IMHO. I think a better idea would be generating (by a script) static .css only once (of course once after every modifiaction ;) ) – in the development time. The presentation layer in the final product wouldn’t be confused by some logic stuff…

Creating some logic layer in the presentation layer might lead to some bad practices (not only the less experienced designers/developers) and i think this is the main disadvantage of this idea.

As long as the processed file is validatable I don’t really see a problem. We all routinely submit pages generated on the fly by server-side scripts to validators to check the processed results, never the raw, unprocessed script.

If for some reason you really wanted to make the unprocessed CSS validatable, how?

One way would be to use comments to contain the preprocessor trigger, e.g.:
color: #000; /* <navbordercolor> */</navbordercolor>
or
#000 #333; /* < #000=colorA> < #CCC=colorB> */</></>
That would require more parsing logic but nothing extreme; you’d just need to parse the line and perform global replacements on that line only. It’s conceptually similar to your technique, just requires a much longer replacement trigger than “$color1”!

Alternatively, you could use valid but improbable placeholder values, such as:
6;
color: rgb(-0.123,128,0.456);
width: 123.456;
...in which peculiar values, negatives, and decimals that you know will never be used realistically in context can be safely replaced with variable strings globally throughout the file. This one makes me nervous for its lack of unique variable indicators (like PHP’s $) but could work.

Paul

.
.

$ua = get_browser();
$IE = ( $ua->browser "IE" );
$NS = ( $ua->browser “Netscape” );
.

.
?>

html, body {
|

|
font-size: < ?=($IE ? "x-small" : "small")?>;
|

|
}</>