Distributive designs are very important in large institutions – especially educational environments. Through two major design changes in 4 years, and a distributed design over a thousand of virtual hosts and 50+ servers I’ve learned a few things about creating a distributive web design which I thought I could share with the community. The challenges are many when distributing a web design which needs to work across many web servers and workstations utilizing different operating systems, but by following a few simple techniques you can simplify design upgrades and synchronization for your distributive web design.

Distributive designs are becoming more popular even as CSS combined with web standards takes hold within educational institutions. By abstracting the presentation from the content of your site, the visual appearance can be applied externally for small or drastic design changes. Through the use of Cascading Style Sheets (CSS), designers can make fluid design changes across an entire website – as long as this stylesheet files (and perhaps other files) are synchronized between all the servers.
The challenge is how to link to this common style. There are many methods of addressing files locally on the same server or externally on another server. I’ll step through the various linking methods and highlight some advantages and disadvantages of each.

“Why not use absolute addressing to one official copy of the CSS file?”
Such as: <link rel=”stylesheet” href=”http://www.example.com/officialsitestyle.css” />

This practice works well for small designs and close teams.

Advantages:

• Very simple to get running
• Easy to update
• Cached once

Disadvantages:

• Large designs will require more than just a CSS file (javascript, snippets of html etc)
• Creates notices of insecure items when accessed through https
• Some IDE’s will not render a design if the CSS is not locally referenced

“What about relative addressing?”
Such as: <link rel=”stylesheet” href=”officialsitestyle.css” />

Relative addressing works well for small sites all working at the same level.
Advantages:

• Simple to distribute
• Works in nearly all IDE’s
• Files can be previewed offline using file://

Disadvantages:

• Limited cache support
• Hard to synchronize many copies without symbolic links/aliases all over
• Leads to many duplicate copies on sites with a large vertical hierarchy

“What about site – root addressing?”
Such as: <link rel=”stylesheet” href=”/officialsitestyle.css” />
Advantages:

• Moderately cacheable (domain specific caching)
• Easy to distribute
• Each server only needs to maintain one copy

Disadvantages:

• Files can’t be previewed directly using file:// as the browser has no context of the site root

As you can see, each method has advantages and disadvantages. If you have a very small design style, and don’t have to worry about secure pages or can easily modify the css link to be secure, you should be fine with absolute linking to one file. Relative addressing works for small teams where communication is good, and you aren’t developing within a deep site hierarchy. The disadvantage is that it leads to many copies which doesn’t work well for pushing out updates.

In our workshop, we use site-root relative addressing, meaning the files are all referenced from the site root so each server just maintains one copy. To overcome the disadvantage I noted, Dreamweaver 9 can generate a temporary file with the content of the referenced CSS files – which fixes that issue.

Site-root addressing works the best for our distributive web design, it may not work for you, but I hope this gives users some advice about the differences when they choose a path to head down. Keep in mind the technical challenges related to updates – keeping many servers in sync can be a difficult task. Expect a post on synchronization when I get around to it.