Published in CSS on Thursday, February 17th, 2005
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?
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.
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:
|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.
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.
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:
Let's have a look at these issues independently, and then bring it all together to build an ideal strategy.
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.
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:
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.
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.
Taking into account what has been discussed, our manageable CSS for a larger site would:
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.
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.
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!
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..