How I Organize my Stylesheets | August 14, 2003

A couple of weeks ago there was a big discussion on css-discuss about how people structure their CSS files. Here is what I do.

First off I try to break my styles down into logical chunks. I'll have a basic stylesheet that I'll serve up to Netscape 4 and within this I'll import the more advanced style sheets. On a simple site this may just be a single stylesheet, but on more complicated sites I'll break this stylesheet down further, usually having one for layout and one for styling. On the Message site The nav was a complicated little problem on it's own, so I gave it it's own stylesheet. I also used the FIR image replacement technique on the homepage headings and so created a separate heading stylesheet as well.

This breaking down of styles has two very useful results. First off it makes it very easy for me to find styles. If it's a layout style I need, I simply go into the layout stylesheet, whereas if I want to change fonts or colours, I go into my styling stylesheet. It also makes bug fixing easier. If I find a difficult problem I can stop importing one or more of the stylesheets to locate which stylesheet the bug is in.

Within the stylesheets I tend to add styles relating to their position in the flow of the document. Anything that is page wide I'll add at the top, then I'll add styles for my headers/branding, my nav, content and then footers (assuming thats the order these elements appear in the page).

Some people have suggested odd methods like having all the id's first, then the classes and finally the html elements, or setting everything out in alphabetical order. This is great if you can remember the type of element or it's name, but not much use if you can't. By laying everything out as it appears in the document, it's much easier to find the style you want. Also because you styles are following the flow of the document you're less likely to get any odd cascade problems.

Finally it makes life a lot easier to debug the code. I sometimes need too comment out chunks of CSS and HTML to locate a bug. It's much easier to do this if you know that the chunks of CSS you comment out are in the same order as the HTML, rather that having to comment out lots of sections in your CSS just to isolate one section in your HTML.

Posted at August 14, 2003 9:12 AM


zlog said on August 14, 2003 10:15 AM

“odd methods”? :P

You make some good points against it but I’m still standing with my methods. One of the problems with your approach is that come a redesign your css file can’t just be altered it would need completely redoing again as the document layout (xhtml) might be different.

I don’t really think there is any perfect way to do it so my advice is stick to what you like/find easiest.

Andy Budd said on August 14, 2003 10:28 AM

Sorry, the method you use (as do lots of people on css-discuss) just seemd a bit counter intuitive to me. However it’s really a matter of personal style. I wasn’t meaning to slag your method off in any way. Just really wanteed to outline how and why I do it.

On the topic of redesings, it’s only a problem if you actually change the flow of the document. I’d agrue that if your xhtml is structured correctly and semmanticallly, you probably shouldn’t need to touch your xhtml to redesign. In fact part of the reason for using css is that you seporate desing from content and thus shouldn’t really need to do this.

On saying all that, I knocked the css for this site up really quickely so haven’t done any of the style splitting (yet). Also things are roughly in the right place in the css files but ont always. Finally not being familiar with the MT templates I’ve probably made a mess of the underlying code as well. I’ve deffinately added stuff that probably doesn’t need to be there.

However in my defence, the site really isn’t officially “live” yet. I’d posted the site to the css-discuss list for bug checking (which I’ve got a load of still to do). However a few sites like picked up on my blog so have started to get a bit of traffic, even though it’s not finished.

For instance, the whole comments page hasn’t even been looked at yet and is basically the orgional MT template getting confuseed about my new styles.

However I’m going off on a big tangent now, so will shut up.


zlog said on August 14, 2003 10:33 AM

“you probably shouldn’t need to touch your xhtml to redesign”

While it’s true you shouldn’t need to, you often do. For example floats. If you are floating something (say an image) it has too be above (in the xhtml) the thing it wants floated “around” (that isn’t the right word but i’m not sure what is ;]).

Dya get me?

z said on August 14, 2003 3:52 PM

“you probably shouldn’t need to touch your xhtml to redesign”

That is a wonderful ideal but in practice I find that the simple generic structures I create for a layout can be insufficient when it’s time to redesign. Zlog’s point about floats is well taken. It almost seems as though, in order to future-proof your markup, you’d need to wrap extra containers around almost every chunk of the page. These extra containers might not do anything in the initial design, but they will save your cheese at redesign time.

The downside is obvious: markup gets littered with meaningless divs. To save bandwidth and create clean structure I usually end up not creating all those extra divs…and then wish I had later on.

z said on August 14, 2003 3:55 PM

Oops, forgot to make the point. The point is that the goal of separating structure from presentation gets undercut slightly by the demands of layout. Even though div id=”menuwrapper” contains no presentational junk, it exists only to serve a presentational need, not for structural reasons.

oli said on August 14, 2003 4:57 PM

I’m interested to read about the splitting idea. I’ve never split style sheets (more than the dumb/smart browser split) because each extra file is an extra server hit I guess. Also is there a cunning reason behind putting the @import CSS files in the head-linked CSS file, rather than in the head itself? The viewer’s browser has to get the HTML file, then the linked CSS file, before it even finds out about the @import files.

The only reasons I can see for not doing it your way would be speed and to reduce server load. However the page sure loads fast in Japan ;-) Nice design too! Keep it up

peace - oli

Andy Budd said on August 14, 2003 6:10 PM

I think you’re going off on a tangent here. If a redesign simply involves wrapping some elements in a container div, or adding a few blank div’s for float clearing, this won’t greatly effect the structure of the mark-up so won’t cause a problem with the way I lay out my style sheets. All i’d need to do is find the appropriate point in the stylesheet that corresponds to the appropriate point in the document flow where the new markup was added, and hay presto, your done.

The only way laying out your styles in accordance with the document flow could cause problems come redesign time, is if the whole document flow changes. However I really can’t see such a huge change in the document flow happening with most redesigns. Headers and branding will usually appear first, content in the middle. footers at the end etc.

This is what I was meaning about semantic markup. The overall structure of the document should not need to be radically changed come redesign. A couple of extra div’s however is no biggie!

Josh said on August 30, 2003 9:13 PM

Andy, I’m interested in hearing (reading), what you have to say in response to oli (2 comments above). Is it multiple server hits when you seperate your css into multiple files?