As more large scale sites are migrating towards CSS, it is becoming apparent that the management of complex CSS documents is somewhat of an issue. What follows is the first post in a two post 'series'. Here in the first post we look at some of the ideas being used to manage stylesheets and the results of these tradeoffs. The second post will look at the balances that we can use to keep those results in check.

The "young-old" technology that is CSS has proliferated over the last few years thanks to projects like the Wired redesign (and later more high profile redesigns, more examples...) and the CSS Zen Garden.

Along with this, more and more designers are adding CSS to their toolkits and making their lives easier. Or are they?

Is it easier?

Not too many people - once they get into css - will argue that laying out and styling a website is harder with CSS than with tables. However it is becoming evident that managing stylesheets can be a difficult task on larger more dynamic and complex sites.

Stop the presses!

Before I go any further I need to stop and dispel a myth. When I wrote about gzipping CSS files, some people, either though e-mail or blog posts, indicated something to the point of "if your CSS files are large, you don't know what you are doing. Compressing them seems a little overzealous". Well, lets look at the following table and see just how small CSS files really are:

CSS file size details for some popular CSS based sites. The size is the sum of all of the screen type style sheets for the given site. Single line refers to code where line breaks are only present between selectors.

Name	Size of CSS (kb)	Notes
www.mezzoblue.com	20	325 lines of single line in the largest sheet
www.stopdesign.com	42.75	1200 lines in the largest sheet
www.wired.com	27.28	1014 lines in the largest sheet
espn.go.com	20.81	799 lines in the largest sheet, appx. 1/3 single line
www.blogger.com	26.52	1200 lines in the largest sheet
www.travelocity.com	31.79	400 lines of single line css

All of those sites have over 20 kilobytes of CSS, and when you are getting up to over 1000 lines of code, whether it's cleaned of line-breaks and whitespace or not, you are dealing with something rather large and complex. Size is an issue, and furthermore management becomes an issue.

But how often do you really tweak your CSS after a site is built?

For many sites the CSS will remain fairly static after it launches.

I know that I won't be making too many changes to the css for this site, once I get the bugs worked out. I bet Doug hasn't done a whole lot to his CSS files since he re-designed, but what about a site like www.travelocity.com? Or that special promotion you have to add to the site one month and change the next?

The truth is that for some sites out there, CSS isn't static. And for many larger sites out there that require a fair amount of CSS (or simply sites with more complicated layouts), having clean, commented and organized stylesheets is an asset.

Writing manageable CSS - the decisions

One thing that becomes clear right away after examining the CSS files for the sites outlined above is that there are some decisions that need to be made from the outset about how you are going to write manageable CSS:

1. Dependant or redundant?
2. How are you going to manage your hacks?
3. Will you be optimizing it to single line for the live files but leave it multi-lined for coding?
4. Will you be splitting up your stylesheets by purpose for easy management? (see digital-web, bleach)

Let's have a look at these issues independently, and then bring it all together to build an ideal strategy.

Dependency vs. Redundancy

Dave does a great job of tackling this issue in his post "Redundancy vs. Dependency". There is a spectrum between the two, and where on that spectrum a set of stylesheets should lie will depend on the project.

However in the scope of this article, dealing with managing larger more complex stylesheets, redundancy is generally favoured.

Hack Management

This issue is an important one as hacks are a necessary evil when it comes to building a site with CSS. While overall a very useful article, Integrated Web Design: Strategies for Long-Term CSS Hack Management gives three little pieces of advice that I think are very important:

1. Know CSS and know your hacks
2. Comment, comment, comment
3. Surgical Correction Strategy

By applying the three tips above, one should end up with less hacks (knowing your hacks means knowing when to use them), which themselves are well documented (commented) and easy to remove (surgery). The result is a set of stylesheets that are easier to manage.

Multi-line to single and separating stylesheets by function

I put these two items together because they present similar trade-offs. If we want something that is easier to manage we're more than likely going to have greater code bloat and http requests, due to extra stylesheets, whitespace and line breaks.

[h4]No big deal?[/h4]

Some people would consider these non-issues. Extra sheets means a couple of extra requests, nothing too hard for a multi-threading browser. And CSS programs like TopStyle will zap your files into single-line with ease, so having a multi-line version for working and a single-line version uploaded isn't too difficult; even better if you have a little script to do it for you (single-line your file and then upload it).

[h4]A look at reality[/h4]

But remember, we're looking at managing a file for a larger site here. Multiple stylesheets for a complicated (multi-themed, multi-tiered navigation) extranet could mean 4-5 sheets: color, nav, layout, forms, tables etc.

In addition to the above, have a crack at the source for the espn home page, and you may start to think that extra requests do matter. Work on a site on a daily basis (perhaps tweaking the CSS styles weekly, sometimes daily), and you'll also find that zapping your CSS to single line in order reduce it's size before you upload it is a pain in the you-know-what.

So where does this leave us?

Taking into account what has been discussed, our manageable CSS for a larger site would:

1. Be coded overall on the side of redundancy.
2. Be well Commented.
3. Contain hacks in extra, hack specific stylesheets.
4. Consist of more than one and possibly several stylesheets for easy management.
5. Is multi-lined locally but hopefully single lined on the server for cheaper downloading.

Looking at the above, it is fair to say that the result of having a well documented and organized system in place for your stylesheets will be more code and more http requests to the server. While we all know that CSS need only be downloaded once and then cached, there are some easy ways to mitigate the resultant extra code and requests.

Balancing the bloat

So what can be done to balance this bloat that is a result of these methods of stylesheet management? Well, click through to Applied CSS Management and Optimization where some common methods of managing and optimizing CSS are outlined.

Discussion

Please use the comments below to discuss the matters outlined in this article, and please at least skim Applied CSS Management and Optimization before commenting here, as your comment may be more appropriate to that post. Thanks!

Check out the blog categories for older content

• 9 Rules
• Application Programming Interfaces
• Blogging
• Contingency Design
• CSS
• Fiftyfoureleven
• General
• Link Wrap
• Marketing
• News, Rants and Ephemera
• Programming and Scripts
• Search Engines
• Web Development
• Widgets that Work
• Working on the Web

The latest from my personal website,
Mike Papageorge.com