jetboy - 11:42 am on May 28, 2008 (gmt 0)

Ian,

For my 2 cents: I've been leading the front-end build for a market-leading travel-centric web developer for the last few years. The basic HTML and CSS hasn't been reinvented for each site; it's evolved from site to site. We've tried some things out, been down some dead ends, and when I left this role we had a pretty stable system in place. We're talking large e-commerce sites though, so for those working on five pagers this is going to be unnecessarily complicated.

inline.css
Starts with the base font definition, then goes on to headings, paragraphs, lists, images etc. This is always the first stylesheet to be linked in. Styles tend to be weighted towards defining the actual HTML elements. i.e.:

h1 {
}

h2 {
}

p {
}

ul {
}

block.css
Followed by block.css, which contains multi-columns structures, data table formatting, subnavigation, gallery and any other block level structures that are used on multiple pages. Styles in block.css can override styles in inline.css, primarily with descendant selectors. i.e.:

.bust-out {
}

.bust-out p {
}

.bust-out ul {
}

.bust-out, when assigned to a div may invert the background colour of the box, and the following declarations would style the p and ul elements to complement the new background colour.

my-page.css (example)
This (optional) stylesheet to be linked in is the page-specific stylesheet, which should have the same name as the page it applies to: about-us.css for about-us.html for example. It would be nice to think that there would be no styles in here, but in the real-world, working in a team, developers don't always follow the style rules. I'd rather any tweaks and hacks were in here than inline or stuffed into one of the main stylesheets.

template.css
Followed by template.css, which contains any CSS for areas that will not change over the whole site: CSS resets, header, footer, main navigation etc. As a lot of these elements are going to be unique, such as the logo, affiliation logos in the footer etc., they are referenced with their own IDs rather than descendant selectors. i.e.:

#logo {
}

instead of:

#header .logo {
}

This is good enough for smaller sites, but for bigger ones, you'll find that block.css starts to get really big. If it does, you should break it out into sections, such as section-subnavigation.css, section-gallery.css etc., for block-level structures that aren't used on every page. These can then be linked into only the page that need them; cutting down on loading in unnecessary CSS. The linking could be done straight from the HTML, or the page-specific stylesheet could import the others.

The end result will be lots of stylesheets, which if all your developers understand the system, will be a hell of a lot easier to deal with than one monolithic stylesheet. It's also great for caching, but unfortunately sucks for keeping the number of server requests down. That's one extreme. With any server-side language you have the option of merging together stylesheets server-side before delivering them to the browser, so you could have 50 stylesheets to work on, but chuck out that one giant stylesheet to the browser. That's the other extreme.

Somewhere in the middle there's a compromise that'll balance server requests with browser caching. That line will be different on every site, and is really something you should look at after the site is built but before it's launched. Consider it performance tuning. If you do this, you'll find out that you're following one of the tenets of object oriented programming: Separate that which changes from that which stays the same.