Introduction

This article will show you how I get the most mileage out of my CSS using a bit of Radio magic. That being said, don't look to my website as a shining example of CSS usage. I just learned the absolute minimum required so my site would not look too horrible and then decided that content was more important than form. Which brings me to my point.

The idea of CSS is that in the hands of a reasonably skilled practitioner, it helps in the separation of content and presentation. This is supposed to be a good thing. What if you're really lazy, and like to use the same CSS for many sites...

I use UserLand Radio 8.0 to manage the content, but what about all the CSS? It's surprisingly similar across the sites. In fact, it's exactly the same except for the color values, so how do changes in the main CSS sheet get propagated to the other sites?

The Magic of #prefs

I'm assuming you know your way around Radio well enough enough to poke around in the user section of radio.root and that you know how things work in the www folder. Please read the whole article and understand it before you start poking around in your system.

If you lift the hood, Radio has a very versatile system of managing the flow of raw content from your local machine to formatted HTML (or whatever you want) in another place. Part of the elegance comes from the #prefs files that can live on any node in the www file tree. These #prefs are heirarchical and can be propagated down the tree. They are overridden by new #prefs that are "closer" to the file being rendered.

You include the value of a #prefs identifier by enclosing it in a special character sequence. For example, suppose you have a #prefs file like this:

#categoryName                 "radioUser"
#glossCategoryName            "radioUser"
#categoryTitle                "radioUser Weblog"
#cssPath                      "categories/radioUser/css/"
#codeSamplePath               "c:/program files/radio userland/"
#codeSampleBackgroundColor    "#EEEEEE"
#codeSampleBorderColor        "#888888"
#bodyColor                    "#000000"
#bodyBackgroundColor          "#FFFFFF"
#headerBorderColor            "#888822"
#headerBackgroundColor        "#EEEECC"
#headerImage                  "categories/radioUser/images/donutmug-mid-trans.gif"
#contentColor                 "#000000"
#contentBackgroundColor       "#FFFFFF"
#dayColor                     "#000000"
#dayBackgroundColor           "#FFFFFF"
#dayBorderColor               "#888822"
#dayRuleColor                 "#888822"
#itemRuleColor                "#888822"
#sidebarPath                  "categories/radioUser/sidebars/"
#sidebarImagePath             "categories/radioUser/sidebars/images/"
#sidebarColor                 "#000000"
#sidebarBackgroundColor       "transparent"
#sidebarRuleColor             "#888822"
#sidebarItemColor             "#000000"
#sidebarItemBackgroundColor   "#FFFFEE"
#sidebarItemBorderColor       "#888822"
#footerBorderColor            "#888822"
#footerBackgroundColor        "#EEEECC"
#autoParagraphs               "false"

If your source code contains the sequence <%bodyBackgroundColor%>, then when Radio renders the source, the sequence is relaced by #FFFFFF. This is all very good, but Radio does not render the raw CSS files.

Rendering CSS Pages

When Radio renders a source file, it passes the source through a series of templates that you can specify in each directory. For each website I manage, I have a css directory that contains - wait for it - the CSS files for the website.

If you've played with Radio at all, you know that the basic #template will not give us reasonable CSS after rendering, so we'll need a really simple template to get the job done. It will have to live in the css directory to make sure it overrides the default template. This is the template I use to render my CSS files...

#renderedFileExtension "css"
<%bodytext%>

Basically, it tells the rendering engine to make the file extension .css instead of the default of .html - there's probably something I can tweak in Radio but this works and is explicit. Then the <%bodytext%> macro is replaced by the contents of the original CSS file. The result is upstreamed someplace that depends on the contents of the closest #upstream.xml file.

Next, we'll need to tell Radio to start rendering CSS files. As expected, there's a value we can set in the user section of radio.root, so jump to:

user.radio.prefs.typesToRender

Make a duplicate copy of the table entry called text/plain and change its name to text/css

So far so good, any CSS files you have should now be upstreamed after passing through the templates. How can we take advantage of #prefs and rendering to make managing CSS easier? Keep reading.

Using `#prefs` with CSS

Now that we have our CSS files running trhough the renderer before we upstream them, it's obvious what the next step is going to be. We'll make a standard CSS file and use #prefs to manage the look of the site. I'll spare you the gory details of reading an entire CSS file, but here's an interesting snippet from the one I use for rendering preformatted boxes on this site:

PRE.codeBox{
  MARGIN:  1.0em 0.5em 1.0em 1.0em;
  PADDING: 0.5em 0.5em 0.5em 0.5em;
  BACKGROUND-COLOR: <%codeSampleBackgroundColor%>;
  BORDER: 1px solid <%codeSampleBorderColor%>;
}

When this passes through the Radio renderer, it comes out as:

PRE.codeBox{
  MARGIN:  1.0em 0.5em 1.0em 1.0em;
  PADDING: 0.5em 0.5em 0.5em 0.5em;
  BACKGROUND-COLOR: #EEEEEE;
  BORDER: 1px solid #888888;
}

Which is exactly what we want.

Now it's possible to use then same CSS file for many categories which can be changed simply by updating the #prefs in the category. Combining the Radio rendering system with preferences makes for a very powerful approach to content management.

Of course, you'll need to have a way to link a CSS file to a rendered HTML file, that will be an article for the future. Email me comments on this article and I'll be motivated to write the next one :-)