Published in CSS on Thursday, February 17th, 2005
In Discussing CSS Management and Optimization we looked at some of the methods used to code and manage CSS, and saw that taken together they could result in a lot of code spread across several stylesheets. In this post we will look at some methods for dealing with that extra code and those extra http requests.
Before we get into the good stuff, a few little notes about dynamic CSS, something used in a few of the ideas discussed below.
Many people are toying with the idea of dynamic stylesheets by doing some server side magic with their CSS by parsing it (with php, asp etc.) before it leaves the server for the client. As we will see below, this helps to offset some of the issues that arise from managing stylesheets that we discussed yesterday.
One thing that I cannot stress enough about dynamic CSS is that you do your homework first, and by this I mean test your stylesheets, make sure that they cache properly (see 'Does it cache?') and make sure that you send them with the correct headers (
header("Content-type: text/css"), for example).
Hacks are a necessary evil of CSS, and managing them well requires commenting, resulting in code bloat, and possibly extra stylesheets, resulting in extra requests.
The second method, browser detection, can be done with your scripting language or conditional comments. Using PHP, for example, comes with the bonus that you can comment for free in the PHP and not worry about delivering the comments to the client.
I remember back in my pre-programming days building a site and using some functionality in TopStyle to convert the rules in my stylesheets to single line and remove extra whitespace. This was for a brochure site, but nonetheless changes later on were a real pita. In addition, the savings just weren't that significant, especially when compared to a compressed stylesheet.
Here the decision is quite simple. If the stylesheet is small enough, compression may not be worthwhile and converting rules to single line not that painful, otherwise I think compression is worth it.
As I outlined in the previous article, splitting up the styles for a site by purpose can be quite helpful. Some people could go to extremes *cough* and easily have > 5 sheets, for example. To be honest, it is really quite helpful to have your navigation rules on one sheet (for sites with complex multi-tiered navigation, for example) and layout-bound background images organized on another. But won't all of this come at a cost?
I know that some of you are saying, 'no, CSS caches, dummy', and yes fine it does, but some sites have more than just CSS coming down on that first visit, so why not make it as pain free as possible?
A while back I wrote a(nother :-) post about organizing CSS, covering a few different ideas where you can put CSS to work with PHP to help keep things better managed.
In the article (see 'Stitch'em together') I outlined an idea whereby using PHP you could stitch together your various stylesheets, thereby reducing browser requests and ultimately turning many sheets into one, and said that I would test it out and report back.
Well, I have put the method to use in places and I can almost safely say that it works just fine. I am using it here on this site, where I have 4 separate sheets beyond "basic.css":
These are all happily sutured together into theRest.php with the following code (Note: headers are handled in another place):
<?php include("$_SERVER[DOCUMENT_ROOT]/css/layout.css"); include("$_SERVER[DOCUMENT_ROOT]/css/layout-style-orig.css"); include("$_SERVER[DOCUMENT_ROOT]/css/typo.css"); include("$_SERVER[DOCUMENT_ROOT]/css/typo-style-orig.css"); ?>
Bringing this all together, what would be the ideal way to set up stylesheets for a site? In the end it depends on many factors, the size of the site and CSS, the time the author wants to waste fishing through their CSS etc., but the following is how I like to lay things out:
Some extra things that can be done:
Well, if you've made it this far you deserve a thanks for reading all of that!! Feel free to sound off your IMO's in the comments ;-)
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..