CSS Architecture Overview

As a technology architect who has an emphasis in web architecture, one thing that I find that most ASP.NET completely misunderstand is the concept of CSS architecture.  It's incredibly important to learn that CSS is not simply "styling". This is one of the most common misconceptions about CSS in existence. CSS is more than the silly “style” attribute on XHTML elements. If that were the case, then none of us should ever rely on CSS as the “style” attribute does little more than dramatically increase the coupling between page structure and style.

Fortunately , however, CSS is more than simply "styling". In fact, CSS is an acronym that stands for Cascading Style Sheets. It's not just some nice marketing acronym used to make the technology sound cool, but is rather a very well thought out acronym that explains CSS very well. When most people come to CSS, they only look at the middle letter ("style") and completely ignore the other two letters completely. You need to understand each of the letters in order to fully grasp the architectural power of CSS.

The third letter represents CSS is "sheet". This means that CSS is a technology designed to be placed by itself in its own file.  By keeping your CSS rules away from your XHTML structure you are maximizing the potential of your system be removing all coupling and maximizing cohesiveness. That is, your XHTML is doing what it does best by representing the page structure, leaving CSS to do its job by focusing on the visual elements. There is no sharing of responsibilities and the aren't directly tied to each other, thereby allowing reuse of your CSS rules.

There are secondary reasons for doing this as well. One of them deals with manageability.  Instead of being forced to change each "style" attribute on each element across multiple files manually, you now have a centralized place for your style.  Saying "it's just one 'style' attribute, what's it going to hurt?" is a sign of laziness and unprofessionalism that will leads only to more people saying the same thing leading to a complete nightmare of spaghetti code. Imagine if people did that with C# and ASP.NET: "what's the big deal? It's only one script block." You can destroy anything by taking cutting corners.

Another secondary advantage of keeping your CSS in "Style Sheets" (CSS sheet) is that it keeps your client download time to a minimum. If you keep your CSS away from your ASP.NET/XHTML structure, your client web browsers can cache the XHTML document and CSS page separately.  When the ASP.NET/XHTML page changes, the web browser doesn't need to get all the CSS information again. In the same way, if you need to change the "style" of something, you can do so in the CSS sheet without affecting anything else. If you kept your CSS either in the "style" attribute as a sloppy blob of CSS rules in a <style/> element, then even the slightest color change is a modification of the ASP.NET/XHTML structure leading to a recompilation.  You may have killed your page cache as well.

The cascading nature of CSS, or to the “C” in CSS, is also at the heart of CSS architecture. If you manage your CSS sheets correctly, then you should have a system where you can literally change one file and have it reflect across potentially thousands of pages. Your changes will naturally flow from XHTML page to XHTML page, from CSS to CSS, and from parent elements to child elements with well thought out, virtually object-oriented element style overriding. Trying that with HTML or with CSS coupled to your XHTML elements or pages!

By working with CSS as true CSS, not simply as a nice technology to change font sizes and colors, we are able to take the potential of CSS to its logical conclusion: CSS themes. If you create a set of CSS sheets that specify the images, layout, colors, and various other style related aspects a specific look and feel, then you are in the perfect place to allow themeing of your web site.  If the term "theme" doesn't appeal to you, what about the term "branding"?  A few years ago I was involved in a project for a major fast food chain who had about 10 different brands.  They basically wanted 10 different store fronts, which made the resident e-commerce developer about flip out.  However, using a properly designed CSS architecture, I was able to provide a simple, yet powerful branding model.  First, I defined the XHTML structure based on their semantic representation.  Second, I applied a colorless and image-less CSS page which gave each website its element positioning.  Third, I gave each brand its own folder with its own root CSS page and its own images and other media files.  All the developer had to do was look at the URL path to obtain the brand name and then change a single CSS page between brand.  The developer was actually able to sleep that night.

As you can see from this story, CSS themes can be very powerful and save a lot of time.  You could event go more complex in your CSS themes.  For example, you could use a CSS coordinator.  Then is when you attach a single CSS sheet to your XHTML page and have that single CSS sheet contain a series of “@import” statements.  You could then actually change the look and feel of your entire website without ever touching the ASP.NET/XHTML structure and thereby never forcing a recompile anywhere.  I often use this technique to coordinate a CSS page for screen size (800.css, 1024.css, 1280.css) with a theme (plain.css, green.css, blue.css), with a core feature set (report.css, membership.css, landing.css-- which would be tiny, so your landing page is very quick to load).  This technique should look familiar to anyone deep into object-oriented design as it's similar to some of the GoF structural design patterns. Having said that, this is not always a required technique and sometimes it can lead to caching problems itself. For example, how will the page know to get the new CSS sheet? Sometimes it's OK to invalidate cache or to force a recompile.

Another reason for proper CSS design that is continually growing in importance is media specific CSS. Say you created a screen for management that allows simple report creation. You put a set of ASP.NET controls next to the report to allow management to refine the report data. How can you allow management to print the report without printing the ASP.NET controls? How can you turn off the colors of the report to maximize print quality on a black laser printer? How can you remove the application header from the form so that the report prints professionally or to make sure the document prints on one sheet? All these things are possible with media specific CSS. By having one structure stating the content of the document you have a base level entity that can then be transformed to various output media. Media specific CSS works for more than just printers. If you thought ahead in your web architecture and therefore created a proper semantic representation of your XHTML elements and separated your CSS from your XHTML, you can easily add light-weight mobile support with very little effort. When a web browser views your page it will display in all its glory, when a printer accesses the page the buttons and header will be gone, and when a mobile device views the page the sidebar is now hidden, the fonts are now smaller, text shows in place of images, and the menu is now abridged.

You can easily add media specific CSS to your documents by placing more <link /> elements in your XHTML head element.

For example, the following will set a general CSS page, a print theme, and a mobile theme.

<link href="Style/ClassicTheme/default.css" rel="stylesheet" type="text/css" />
<link href="Style/ProfessionalPrintTheme/default.css" media="print" rel="stylesheet" type="text/css" />
<link href="Style/SimpleMobileTheme/default.css" media="handheld" rel="stylesheet" type="text/css" />

One thing you may want to keep in mind about this is that the iPhone is not considered a “handheld” device. To add a media specific CSS page to the iPhone, please see this article.

It's hard to overestimate the importance of proper CSS architecture, yet I find that most web developers have never even heard of this before.  I suspect that it's because its a fusion of diverse topics which with most web developers aren't familiar.  For example, many ASP.NET developers I work with know software architectural principles, but can't even spell CSS.  Other times, I'll see awesome web designers who have no idea what software architecture is.