I've had this idea for a while, and I think it's a good one. I hope someone else will run with it, because I would love to have a tool that does what I'll describe. If the consensus is that it's a dumb idea, then so be it. Web developers who either don't use CSS (!) or are abstracted away from CSS by a WYSIWIG tool or development framework might not be too excited by this idea, but I suspect it will resonate with people who hand-code their CSS. My idea is for a "precompiler" (if that's the best label) for Cascading Style Sheets (CSS).

What I mean by this is a tool that allows me to leverage procedural and object-oriented concepts like named constants, variables, inheritance, and references to increase the coding efficiency and maintainance associated with web sites that have somewhat complex CSS code. Just to be clear, my proposal has nothing to do with changing CSS itself. I just want to get rid of some of the tedium and inefficiency in the coding and maintanence of CSS, especially for sites large and complex enough to be interesting.

When I use the term "pre-compiler" I'm thinking of the browser that renders HTML content with CSS styles as the primary "compiler." The browser parses the CSS code associated with the HTML (for simplicity's sake, let's assume the CSS is in a separate file than the HTML) and decides how to display the web page. My idea is for a standardized set of extensions to the normal CSS syntax that provide shortcuts for the CSS coder, and a "pre-compiler" that parses the "extended" CSS code to output "normal" CSS code.

Let me try an example:

One of the top features I'd like to see in this CSS extension is named constants. For example, I want to do something like this:

    ~const PRIMARY_BACKGROUND_COLOR = "#FFFFFF"~
    
    body {
        background-color: ~PRIMARY_BACKGROUND_COLOR~;
    }
    
    div.inset {
        background-color: ~PRIMARY_BACKGROUND_COLOR~;
    }
    
    div.inset_reverse {
        color: ~PRIMARY_BACKGROUND_COLOR~;
    }

I think that people who code a lot of CSS, especially complex CSS that is split across multiple files, will immediately see the benefit of being able to define a value that repeats often in the CSS and only put it in one place. This is an obvious use of the DRY principle [1] (Don't Repeat Yourself) that programmers in procedural and object-oriented languages use all the time. We could apply the same idea to all sorts of CSS values: font families, weights, styles, etc.; height and width dimensions; image filenames; border styles--the sky's the limit.

That tilde (~) that I put in front of the const defintion and is just a marker for the precompiler to distinguish this as a CSS extension that needs to be handled. No doubt someone smarter about language design and lexical parsing than me can come up with a better convention. I'm just trying to get the idea across.

(Please keep in mind that this is only a contrived example. I'm well aware that CSS has inheritance mechanisms built in such that DIVs inside of the BODY will inherit the background color from the BODY. But it's often not that simple, and I've run into plenty of flakey browser-specific CSS inheritance issues over the years.)

So the idea here is *not* that we would send this "extended" CSS out to the browser. Rather, we would use our "pre-compiler" to turn this into valid CSS. The benefit to me as the CSS coder is that I can save time and reduce mistakes by defining constant values in one place and then refer to them wherever I need to.

Another idea is what I call "references." For example, I want to be able to say, in effect, "Make this attribute have the same value as the same attribute on this other style." For example:

li {
    line-height: 1.4em;
}

blockquote {
    line-height: ~SAME_AS(li)~;
}

The idea is that we can refer to another style within the same scope, not unlike the idea of the named constant. Again, this is just a contrived example. I'm well aware that we could have just put li and blockquote together in the same style defintion, separated by a comma, but consider that there might be other attributes we don't want to share for these two tags. And also, my syntactic convention with the tildes and the function-like SAME_AS() may not be lexically ideal.

I think there are probably other similar ideas that we could come up with, but I'll stop here. If we wanted to get really fancy, we could introduce the ability to define macros or scripts that could be "called" from within a style definition, such that the pre-compiler would execute that code to determine what the resulting CSS should look like. For example, some simple math support would be useful:

li {
    line-height: 1.4em;
}

blockquote {
    line-height: ~SAME_AS(li) - .1em~;
}

What I like about this is that it allows me to set the style values of some page elements *relative to* other elements.

As far as implementation of this idea, I suppose one could develop a full-blown CSS IDE around it, but I suspect a plugin for an existing tool like Eclipse or Dreamweaver might be a better idea. Myself, I would love to have it as a feature of my favorite text editor, UltraEdit, but if there was a command line compiler that my editor could call, I think that would work just as well and might make for the most universally accessible solution. It would be cool to have a unique file extension to, like *.CSSE, for "CSS Extensions." That way I could configure UltraEdit with the CSS Extensions syntax highlighting rules.

I would prefer to see this as implemented in an Open Source manner, or even better as some kind of standard that could be implemented in multiple tools, commercially or otherwise. But beggars can't be choosers.

Feedback welcome.

Thanks for reading,
Daniel Read

[2]
This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License [3].