akamike (2007-2010)

CSS Organisation and Best Practices

At Lift we have been discussing our methods of organising and writing CSS for new project and future maintenance. It got me wondering how other people choose to manage their stylesheets.

After joining Lift I started to move us over to a system where you have 3 files (excluding reset and ie):

This increased our productivity as we could easily make specific changes that fell under each of the three categories. During a fresh build we could progressively style our documents by approaching the layout first, typography second and colour third (or any other order we wished!). I also recommended running each selectors attributes on one line, like so:


I believe this reads just fine with syntax highlighting and makes it much faster to skim through the files to find a specific selector. Another thing I do is remove the last semi-colon, as it is not needed.

Recently, we had a new member join the team, Kevin Carmody. As a developer working with me, we have been looking to improve our development practices, starting with front-end development. Kevin has happily adopted the practices we are currently using but is unsure of this 3 file split. After much discussion round the studio, it is agreed that it does have some drawbacks but other concepts we talked about also have their flaws.


Another topic up for discussion was the organisation within the files themselves.

In any method, we would like to use appropriate indentation of child elements for easier reading. Also, depending on the organisation and file separation, we find that there are levels of duplication, (for example) where elements have similar styles but are written in separate places, but this is not such an issue as some duplication is appropriate when moderated carefully.

My proposal at the end of this was to retain the 3 file set up but improve our grouping/ordering within the files to further improve readability. We're still thinking about it and are open to new ideas.

What about you? Please share your own practices in the comments or, if you want to go into great length about your methods, post them up on your blog and let me know!


Rachel Nabors

I use three files, screen.css, print.css, and kludge.css, used for screen media, printing, and displaying to older browsers (IE6) respectively.

I use browser conditional comments to hide kludge.css so people with up-to-date browsers won't download extra, sometimes non-compliant, css rules.

Within style.css, I have begun to group things from general to specific and I use "/*= Description */" to mark each section of more specific rules. That way, I can search for the equal signs and jump quickly from section to section within longer documents.

It was not always like this. At one time, I would make style.css into 3 separate files, too, like you do. But then I saw how much all those extra requests slowed down page serving times. On a busy server, the need to reduce http requests is important. So as I moved toward using more CSS sprites and fewer images, so too did I consolidate my CSS files.

Thank you for posting your write up!


@Rachel: I should probably add that this is (or will be) for development only! For content management we use Movable Type, a system that publishes files statically. We intend to have MT condense these individual files into one single file, which would be screen.css (or print.css). It's all part of a larger plan, but thank you for pointing this out as not everyone thinks about that!

The use of an equal sign in each comment to improve search is an interesting idea, should we choose to make use of comments I will definitely consider this :)


There's not really a perfect solution, is there? :)

I use four files: style.css, which imports reset.css, then print.css and ie.css.

In style.css I add a table of contents at the beginning along with a colour palette, for easier reference.

Then I usually structure the file like this:


This structure may vary depending on the project, of course.

I've learned to add a = before each section on Andy Budd's CSS Mastery. I think many people use the same trick.

Also, I write my CSS selectors in one line, and use indentations depending on who's who's child, etc.

I hate extra lines and compulsively delete all the extra lines from other people's CSS :P

Michele Gerarduzzi

I've been using the system detailed by Natalie Downe in these slides (http://natbat.net/2008/Sep/28/css-systems/) and it's been proved very effective and easy to maintain even for big files (2,000+ lines).

Using a tool like CSSEdit for OSX, with his “Groups” feature, helps reducing the visual clutter and keeping the file properly organized.


Is that 2,000 lines one-liners?

Michele Gerarduzzi

@Yaili No :) Multiple lines, one declaration per line


I've been using the same in development as Yaili:
* reset
* style
* print
* ie

When we go live though, we merge and minify the lot into two (+1):
* containing reset and style
* print
(+ conditional ie - how I'd love to not having to do that)

We have been using "one liners" and find them generally much much much easier to navigate through.

We also use comments in the development (same as Rachel (/*= */) to be able to "index" the stylesheet. The comments get stripped out during the minifying process.

Up until today we have not been able to find a tool to "tidy up" the code for us the way we like it, so we're still formatting manually. I'd be interested in any suggestions :)

Thank you for your post, very insightful!

Andrea Gandino

It’s interesting to read what you guys think about this!

Personally today I tend to group selectors following the logical flow of the page's content.

Also, my vote goes for writing CSS rules on one line per selector; as the file size grows, it's much easier for me to scan it to find stuff.

Concerning imports, I split my CSS into five smaller files:

* Grid.css. It's a framework that I made and that manages grids, groupings, float clearing and all of the basic layout stuff.

* Layout.css, where most of the stuff happens.

* Type.css. This is a specific stylesheet that defines all of the typographics goodies that are in place in large portions of text (eg. articles, page bodies). Generally, it doesn't contain rules for font sizing etc, as they're already specified in the Layout.css file.

* Fix.css. This is a newly introduced file in my workflow. As of today, it contains rules for the new HTML5 elements.

* IE.css. IE fixes, of course. This is called via a conditional comment.

In the past months I've been experimenting quite a bit with this kind of stuff. For example, I can understand the advantages in separating layout, typography and colours, especially if more than one person is working on the same project.

Still, I find it quicker for me to write everything in one file, and giving rules an order, for example layout stuff first (widths, margins, paddings etc.), then font-related stuff, and then colours along with all the rest.

Thanks for bringing this topic up, Mike!


I am using similar concept:
- reset.css
- global.css
all the redefines/debug/clearfix
- layout.css
- ie.css
- pagename.css (if needed)

lately i am considering merging global and reset. they both always load and really, reset is nothing as far as file size goes.

also i tend to group similar rules together but i never going beyond 3 per line:

- type related
- background / border
- position
- margin / padding

i was surprised that you go into detail about 'not using a semi-colon' on your last rule but don't get into commenting which i consider the most important way to organize your code especially in situation where you have many people working on the project.

my main comment blocks are basically 2 lines of ====, 60 spaces long.

/* ============= etc...
name ======== */

but like you say, its an ongoing process... always evolving. :)