Daemon Skins: Separating Presentation from Content

We all have our daemons. They lurk behind the scenes, driving us, seducing us. Their powers can be quite magical.

In the Unix operating system, for instance, the many background tasks that occur behind the scenes are controlled by processes called daemons. Following the Unix tradition of keeping the names of things short, a “d” is appended to the end of the name of the task that the daemon controls. Thus the daemon that controls the hypertext transport protocol (http) on Unix based web servers is called httpd. Similarly, ftpd controls TCP/IP file transfer.

As designers, I often think that we have a design daemon (designd) controlling our creative impulses. When my designd goes to work, I can’t rest until I have carried out an idea to its conclusion. I refer to this process as “exorcising designd.”

My latest exorcism took the form of an experiment in separating content from presentation, resulting in several new designs for my personal site. Rather than simply upload a static redesign, I listened to my daemon, and the result was a series of user-customizable “skins” for my blog. In this article, I’ll explain how I did it, why I did it, and what it taught me about the future of the web.

Skins — the “latest in customization”#section2

Skins are nothing new. They’ve been around for a long time on the Mac OS. One of the hallmarks of the Macintosh Operating System has been its ability to be customized — from custom icons to using the shareware Kaleidoscope to customize the entire User Interface. Apple even built the capability into their now defunct Themes. Windows and Linux users have also had the ability to skin their UI for some time. Mozilla has introduced XUL (pronounced “zool”), allowing a high degree of customization.

Software from mp3 players to browsers and more are offering this level of customization to the degree that it has become an important selling point for many people. Skins proliferate throughout software and operating systems, so why not allow people to skin the presentation of content on the web — or at least on my blog?

Skinning the blog#section3

One of the first web sites I came across that allowed the user to change the look was Cameron Barrett’s CamWorld. Jason Kottke used to have several versions of his site as well. Daniel Bogan’s waferbaby allows you to create your own stylesheet right down to the font, its size and color. Contenu.nu’s NUblog has challenged its readership to create a stylesheet to “skin their blog.” This idea is nothing new, in fact it is really what the w3c would have us do (that is: separate presentation from content), if not in practice, at least in concept.

So, after seeing these other sites I decided to embark on my own experiment, to see if I could create a page or a site that completely separated the content from the presentation. In so doing I wanted to allow for maximum flexibility in the presentation, without compromising the content or the markup.

Form versus function or the separation of content from presentation, well almost…#section4

In an ideal world we could use CSS to describe the layout of the content, resulting in a complete separation of the two. Unfortunately we can’t do that yet. Since I wanted the site to be viewable on version 4+ of the major browsers, I still need to use tables for layout.

So I analyzed my site, a weblog. It’s really very simple. I have the main content on one side, and a list of links on the other. I use headings and text as well as several small icons to denote the kind of post that follows or, for the links, the category they fall under. In my style sheet I defined a content class and a links class for table data tags

that can be applied to the table data like this:

. I did the same thing for the img tag so that images in the content can be styled differently from images in the links. And any background images, for the body and/or table cells, are specified in the stylesheet.

Next I went to work creating some new stylesheets to apply. I had to recreate the original look to fit the new thinking. Then I created a stylesheet that was radically different. A third stylesheet is different still. In the process I created the iCDK, or iBlog CSS Development Toolkit. This is a CSS file that includes all of the tags and classes I use in my blog, ready to be defined.

I’m not really a geek, I just play one on the web…#section5

Once I had defined my style sheets, and limited the html layout to a simple table, I was ready to try my experiment. I linked to a different stylesheet in my HTML file, resulting in, wow, a radically different page. But the content was the same. This was cool, I thought. So I wanted to provide a way for any visitors to my blog to experience the same thing.

Normally this could be done with some server side magic, to make the experience relatively seamless for the user. But I am serving my blog off of Apple’s homepage.mac.com servers, so I don’t have access to the server side of things. I have to rely on the client. Time for some JavaScript.

I’m not a programmer, but I can fake it if I need to. I remembered that Porter Glendinning had written some JavaScript that would look at a URI and strip off a named anchor, if there was one in the string. I figured I could adapt this idea for my purposes. If I could grab the name of a CSS file from the end of an URI string, I could use document.write to link to that stylesheet.

I won’t go into the gory details here (but if you really want to know you can read the sidebar), but suffice it to say that I spent a couple of days poring over Netscape’s JavaScript reference site, and learned something about regular expressions in JavaScript. If this

 MyRe=/?(w*).css/g;
 MyArray = MyRe.exec(anchorString);
 anchor = RegExp.$1;

makes you all tingly inside, then you probably don’t need to read the sidebar, as I am sure you could do what I have done much more elegantly and efficiently. Besides, the point of the exercise was not to flex my programming muscles (though it was fun to do that), but to take a single file and its content, and present it in many different ways, all with a single mouse click.

Occult calisthenics (or: Why all the supernatural exorcise?)#section6

In my original design I chose to put the content on the left and the links on the right. This turned out to be a good design decision for several reasons. Since the design is a simple two-column table, it will be a simple matter to change the code from <table>

  to <div class=“content”>
and use CSS positioning for layout, once it is supported in all major browsers. Having the links on the right means less mouse movement when going back and forth between scrolling and clicking links. Since we read from left to right, having the content on the left makes it easier to track the text. With text browsers and voice reading software for the blind, the content is presented first, followed by the links. And it breaks with the common practice of putting the links on the left, making me appear arty and postmodern. And I kind of like that.

Beyond the placement of content, this little exercise has a number of other benefits. In my real job I am a web designer for a federally funded scientific organization. This means that our web site must be accessible. While the Feds are still ironing out what that means, I am trying to get a head start on accessibility issues and web design. This experiment has helped me see that not only is it possible to separate content from presentation, it is desirable.

In this scenario the content is served separately from the stylesheet, so there is no need for a blind person to download the stylesheet or its associated images. Or, as voice browsers become more sophisticated, a separate stylesheet that describes voice inflection can be created and served for those browsers, but the content will remain the same.

Those people who are still using Lynx or other text-based browsers, older browsers, or surfing with a 14.4 modem and images turned off will still get the content, and in a reasonable format. In theory users could create their own stylesheet that would provide better contrast, larger fonts, even images of their own choosing.

And then there are the alternative clients — like PDAs and WAP enabled cell phones. Most of these don’t support stylesheets yet, so they get the text, and the images that add to the content, but don’t need to bother with the background images that provide eye candy.

Everybody wins. And I like that.