CSS constants

A lot of web designers complain about CSS lacking constants you could define once and reuse throughout the CSS document. CSS was not meant for that and does not support it.
What you can do though is use a server side language to simulate a CSS file by setting the appropriate header. However, this means you need to stick to the language syntax.

Playing with that idea, I came up with a small PHP script that parses any CSS given to it via a variable and reads and replaces the defined constants in the CSS.

This page shows how it can be used. You apply the CSS with the invalid constants syntax by looping it through the PHP script:

<style type="text/css">
		@import 'cssconst.php?c=demo.css';
</style>

In the CSS file, you define the constants with the following syntax:

$colour1 = '#999';
$colour2 = '#363';
$colour4 = '#696';
$colour3 = '#cfc';

And you can use them throughout the whole CSS document:

#footer{
	padding:.2em .5em;
	margin:0;
	background:$colour1;
}

Any improvements?

I am aware that this is butchering the idea of CSS as presentation only, and means you design invalid CSS in the raw form, but it fills a gap and it might make CSS maintenance a bit easier. You can still validate your CSS by looping it through the script:
http://icant.co.uk/articles/cssconstants/cssconst.php?c=demo.css.

8 Responses to “CSS constants”

  1. Sebastian Redl Says:

    I think a crucial improvement is that you give the correct cache-control headers. So you need to send a Cache-control with a positive value (forgot which that is), as well as a Last-modified header, which you should generate from the CSS file’s modification date.

  2. Jon Says:

    Why not just include the PHP right in the file and have your css files passed through the preprocessor? Seems a lot neater, no?

  3. Chris Says:

    Sebastian: Correct. I will add that to allow caching.

    Jon: Yes and No. If you know PHP, you are right, if the maintainer doesn’t know PHP, this might be an easier option, as you only need to insert $foo instead of <?php echo $foo;?> or its shortcut equivalent.

  4. linoj Says:

    cool! now I want more :)
    - expressions: margin-right: ($outerwidth – $innerwidth)/2;
    - functions: color: lighten( $color, 0.25 );
    - support for @import in the css
    ok, nevermind

  5. Daniel Says:

    And even:

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

    html, body {
    |
    |
    font-size: < \?=($IE ? "x-small" : "small")\?>;
    |
    |
    }</>

  6. Paul Novitski Says:

    Good work, Chris. I love the elegance of @import 'cssconst.php?c=demo.css';!

    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

  7. linoj Says:

    hi, i need to extend this to pull the constants in from an external file, e.g. constants.css, so they can be shared by multiple stylesheets. Can you show me code that will do this? TIA

  8. Marcin Krawiec Says:

    “I am aware that this is butchering the idea of CSS as presentation only[..]“

    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.

Wait till I come! is the blog of Christian Heilmann , a developer evangelist living and working in London, England. Download vcard.

Feed me, Seymour: Entries (RSS) and Comments (RSS).