Anyways, regarding post #2: agreed (kidding).

Is there a way (in PHP – sorry, I’m not a PHP expert!) to explicitly create/write the output/expanded css file (= css file after the substitution of the constants) on my disk. So I would be able to continue with testing the layout of my website (as I did before with my html-template + my expanded css file) separately in my favorite WYSIWYG-HTML-Editor (z.B. DreamWeaver) + Browser (without PHP!). After the layout testing I would put the files (html/css) separately in my cms backend… (as I did before).

Now (with the PHP server contants in the css file) I am not able to test my html layout any more… !?

Thank’s for help.

[...]

I’ve been working in HTML for years but am only just making the switch to CSS (thank you Eric for an excellent book!). I have come across a number of areas where I am going to have to resort to programming where I might hope CSS to help me: rotating images and setting the navigation style for the active page. Faced with the prospect of two different levels of programming (server-side substitution for the image rotation and possibly Javascript for the active navigation) I’ve been asking myself whether it wouldn’t be easier to program everything in one level. For generated pages CSS should be easy to use and integrate otherwise it may be easier to ignore.

I agree CSS should not become XSLT and it should not become a full programming languages but support for dynamic, context-driven values can be included without this.

ie. a:current – highlight a navigation item for the current page without excessive and possibly tricky use of ids and classes;
{background-image URL:random(image1.gif, image2.gif…);}

Furthermore, pushing this into CSS gives both the designer and the user more control of what is seen.

 #navbar { ... }

will be OK. [In case this doesn't come through correctly either, there's supposed to be a blank space before the '#' in the line above.]

1. Put a space (one or more) before the ‘#’ in the ID’s definition. So,

#navbar { ... }


will cause trouble, but

#navbar { ... }


will be OK.

2. Change the ‘cc’ command in the shell script to invoke “traditional” C preprocessor behavior (which ignores preprocessor commands that don’t begin in the first column). This will vary from compiler to compiler; on the Gnu C compiler (gcc) the correct command is

cat $1 | cc -E -traditional-cpp - | grep -v ^# | grep -v ^$


Sorry for the inconvenience. As it turns out, I seldom use unqualified IDs, so I just noticed the problem.

#define CLIENT_FG #123456
#define CLIENT_BG #987654
#define CLIENT_TXT #012

/* I can then use statements such as: */
body { background-color: CLIENT_BG; color: CLIENT_TXT; }

I have a one-line UNIX shell script named ‘ppcss’ that handles the processing:

cat $1 | cc -E – | grep -v ^# | grep -v ^$

By convention, I name my CSS files *.CSS for the “raw” files (those that contain preprocessor statements) and *.css for the “clean” files (those that contain pure css code, after preprocessing). I edit the .CSS files, then run the command

ppcss foo.CSS > foo.css

to generate the “clean” css file. Note that this script strips comments and blank lines as well as preprocessor statements (which is OK, because I don’t need the comments in the file when I upload it to the web server, and the fact that the comments never have to be downloaded to the user’s browser make me feel better about including lots of comments in my css files).

I’m more of a server-side programmer really, and don’t deal that much in client-side stuff like CSS and JavaScript, but I try to keep an eye on what is going on in those areas as they tie so closely to the backend stuff.

CSS Gradients Demo

There’s one other server-side CSS approach people might consider for constants and variables, and that’s XSL-FO. Or has that been abandoned due to its complexity and verbosity?