developer.* Blogs - Precompiling CSS with Extensions - A Crazy Idea? - Comments

CSS Organization

Daniel Read — Tue, 11 Jul 2006 12:39:54 -0700

As a complement to this thread, I later encountered this nice article in Digital Web Magazine about "architecting" CSS files to avoid the potential for the spaghetti effect discussed above. Worth a read if you're starting a new project and have not yet decided how to organize your CSS.

Dan

This is not a crazy idea

Jens — Sun, 25 Jun 2006 01:53:07 -0700

Years ago I needed something like that for HTML (mainly to auto-create a dynamic menu - well, static for each file, but slightly different from file to file). I ended up creating my own text editor (with syntax highlightning, there is free code around for that) and added a simple precompiler to it. The syntax is somehow similar to PHP: with special tags I can define constants, use them, add if/then/else, include other files, pass "parameters" to these files (which makes them look like procedures) etc. I've decided to have special extensions for "uncompiled" texts like .uhtml, .utxt... and of course .ucss is possible, too. A simple click compiles the .uwhatever to a .whatever, replacing all constants, including other files after compiling them, too, etc. It's even possible to create projects with a simple command which compiles a file without including it. I've never published this editor/compiler because it is too premature, but I'm still using it from time to time, and I still find it useful to have such a precompiler for texts. So I really think this is not a crazy idea.

Create CSS using a template engine

Ilan Schnell — Sat, 24 Jun 2006 22:07:51 -0700

Some of your ideas could be solved by creating CSS code using
a template engine. Usually template engines, e.g. Cheetah
(http://cheetahtemplate.org/) are used to create HTML, but
you can actually use them for creating anything, including CSS.
I've used Cheetah to create Postscript, PHP, XML and plain text.
However, I'm not sure how practial this would be.

CSS GOTOs

Daniel Read — Sat, 24 Jun 2006 21:54:13 -0700

Robert, thanks for all the comments, and yet another solution! I only have a moment for a quick reaction. You wrote:

I have a better understanding of wanting a tool that can understand CSS well enough to refer to information from other rules, but I'm having quite a bit of trouble seeing what it buys CSS developers. The way I see it, what you're asking for, if used in real life, will result in CSS that looks like spaghetti code - you're simply using named GOTO's.

This is a fair concern, and one I'll have to think about. It might mean trying some scenarios with an imagined syntax and seeing how it comes out. I might also argue that CSS already has a serious tendency towards spaghetti-ness. For the recent rewrite of this site's design, which is built within the PHP Template engine of Drupal, as well as in a separate publishing system I use for the articles side of the house, I know the CSS got a little complex. I split the CSS into separate files, and you can develop some concept of namespaces to keep things organized and to allow for variation of the same page elements on different kinds of pages. You do have to go to some effort to keep things clean. And it seems there can be side effects that make the built in CSS inheritance mechanisms not do what you need all the time.

I guess my point is that these ideas were hatched while in the midst of this site redesign, so I'm inclined to give them some credence, but it's certainly possible that you are right that basic string replacement functionality is enough to streamline the redundancies.

Best regards,
Dan

gm4 version done.

roberthahn — Sat, 24 Jun 2006 17:54:41 -0700

Dan, Dennis, and others...

You might want to check out my update to this -- I set it up using the gm4 macro processor, which ended up being as simple to use, and quicker to implement, than I had expected. See CSS Preprocessor - Take 2.

Again, still not your ideal language-that-understands-CSS ideal, but we may have to agree to disagree on that point. I just don't see the advantages inherent in that strategy. Do let me know if you actually use this in a project though; I'd like to hear how it worked out.

I'm back.

roberthahn — Sat, 24 Jun 2006 16:34:39 -0700

Sorry about my blog not accepting your post; I found out this morning, right before running out with my family for the day that the server I'm on went belly-up. It's a shared server, so the usual presumption at this point is that some over-enthusastic developer tried to do something that consumed too much of the server's resources. Anyhow: the blog's back up and running.

Thank you very much for your kind words. I too saw this as a first cut at the solution, and had this mostly written up before I discovered the problem with #foo and cpp. Before seeing Dennis' and your comments on that problem, I mostly convinced myself that it wasn't that bad. As an aside: I'm not quite following Dennis' issue with the "piggybacking on the C code" - Dennis, if you're reading this, please understand that the C preprocessor has nothing to do with the C language - the people who wrote it designed it to specifically solve their problem with writing lots of C code. The preprocessor can be used with other languages, and other text files (and indeed, this is how I used it).

In any event, I'm going to have a look at using gm4, which won't have this conflict with id selectors. I realized, after posting my article, that for this type of exercise, gm4 might be a better fit -- the problem with gm4 is that it's too powerful, it's really hard for many developers to pick up, and can match things a tad too aggressively if you set it up wrong. For those reasons I instinctively reached for CPP.

After reading carefully through your post and this response, Dan, I have a better understanding of wanting a tool that can understand CSS well enough to refer to information from other rules, but I'm having quite a bit of trouble seeing what it buys CSS developers. The way I see it, what you're asking for, if used in real life, will result in CSS that looks like spaghetti code - you're simply using named GOTO's.

In the case where you want your li and blockquote rules share the same font size definition, I'd probably still would want to just define it in a set of constants (using names like default, caption, header1, header2, header3), and, if I find I'd need to tweak a size, I'll either adjust it on a 'global level' or simply change which constant to use. For arithmetic support, well, maybe using gm4 might actually help here, because it promises arithmetic support -- you'll have to get pretty savvy with the macro definitions though, to split the numbers from the units, do the math, and merge it back in -- and then that doesn't help solve the problem of wanting to merge 12pt with 0.8em.

I'll post another update here if I get the gm4 version working. I really like this basic architecture (a sh script executing multiple preprocessor commands, all executed by launchd), and fully intend to add this to my arsenal of tools as well. The strong point in the arch is that you can swap out the cpp part for anything, and the rest of the infrastructure would require only minimal changes to accommodate.

Reply to Robert's CPP Solution

Daniel Read — Sat, 24 Jun 2006 08:40:10 -0700

Hello,

I wrote the following comment to Robert Hahn's excellent post and solution, to which Robert links in this comment up-thread. However, I think Robert's server was having some trouble at the same time I was posting the comment, so I am pasting the comment below.

Best,
Dan

*****

Robert, this is great! Thanks for taking the time. In addition to being a nice initial solution to the problem, it's an excellent demonstration of the power of generic tools like CPP and launchd. While reading your post, I was thinking of how easy it would have been for the original designer of CPP to make the tool less generic.

The clash between CSS and CPP on the meaning of the # character is an unfortunate side effect, even more so because I use this convention in my CSS liberally--that is, starting a style definition with the # character, as in your example foo:

#foo {
    ...
}

I suppose CPP could have been designed to be even more generic if the definition marker character was configurable. Easy to criticize the play from home after the match has already been played.

Previously, Robert, I described your solution as an "initial solution." In this, I meant no disrespect, because I think it's infinitely cool that you've put this together. I'm going to give it a run myself for a new site I'm about to build, and I suspect others will find it useful also. Not to mention, I suspect others will find inspiration from the creative application of CPP.

You mentioned in your post that you had only skimmed my original post, which is cool, and regardless, I might have not done the best job explaining my overall
"extensions" idea, which includes more than the string-replacement functionality from my first "const" example--a problem which is solved nicely by your CPP-based solution. I think a full implementation of the "extensions" idea would need to have more semantic awareness, if that phrase is appropriate, of the specific structure of the CSS code.

What I mean is, I would also love to have that ability to refer to other styles in a manner where this "precompiler" would understand the other styles defined in the scope of one or more designated CSS files as "objects." This to me implies the need to initially parse all of the designated CSS files to build a graph in memory of unique style "objects," kind of like parsing an XML file to build a DOM.

In addition, the ideal solution I can imagine at this point (and I'm not pretending to be the most qualified person to do so) would have some ability to evaluate simple expressions and functions, such as the example of saying "I want this lineheight attribute value to be .1em less than the lineheight attribute of that other style over there."

Thanks also for the introduction to the term "lazyweb request."

Best,
Dan

P.S.
The timing with the Slashdotted interview you mentioned is coincidental. I've been sitting on this idea for awhile and finally the other night decided to blog on it since it was clear I was not going to have the time to do something with the idea myself. I imagined, however, that I could not have been the first person to think such thoughts. The need for these kinds of "extensions" would be apparent I think to a lot people coding CSS of interesting complexity from scratch. I'll have to go read that interview.

CSS compiler...

Dennis Nagel — Fri, 23 Jun 2006 21:09:05 -0700

I too have had this very thought. At the time, ignorant of the CSS specification, I searched in vain for such an animal in the wild w3. I eventually came across the spec, and my dream was flattened, but still alive. I considered writing a Q&D VB EXE that would pre-process my css and never found the time. Roberts suggestion is much cleaner that I would have come up with, but I don't like the fact that it piggy backs on the c code, thus losing native CSS functionality... I'll check back and see if ayone else solves this ... It would be interesting to see if the W3C could justify it's inclusion in the next CSS Spec, however unlikely that rteally is.... Thanks for your thoughts. D.

Built it.

roberthahn — Fri, 23 Jun 2006 19:10:50 -0700

Hey, Daniel. Here's how I decided to tackle this problem, using the aforementioned C preprocessor to do the heavy lifting. I hope this'll work for you.

CPP? gm4?

roberthahn — Fri, 23 Jun 2006 13:32:58 -0700

If I were to tackle this problem, I'd probably just use the C Preprocessor (CPP) and use C-style #define's or #include's, or define a set of m4 macros. Then, each time I make a change to this enhanced stylesheet, I'd run

cpp styles.csse styles.css

and be done with it. It would be nice if that could be done automatically, and depending on what platform you're using (like Linux or OS X), you could set it up to run that command every minute, or when the file changes or something.

Actually, this is interesting enough that I think I'll try building this up tonight. I'll write it up on my blog when I have something to show for it.

Precompiling CSS with Extensions - A Crazy Idea?

Daniel Read — Fri, 23 Jun 2006 07:10:59 -0700

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).