I like the readability of multi-line style declarations, but for my latest project I went with single-line. I find it a bit easier to see the different “sections” of the site this way. Yet to decide which method I like best though.

If I was given enough time I might use alphabetic ordering, but I don’t :p

That said I’m more of a tinkerer than a full blown CSS guru, so some very interesting reading in the above..

IE styles in separate sheets – again, a must.

I’m not a fan of single-line declarations, but we use them at work, so it’s a case of fitting in with the team.

I tend to group my properties logically – e.g. font-related stuff, box-model stuff.

With Firebug I don’t see the need for alphabetic ordering… even though I do suffer from OCD!

Nice article… looking forward to reading more.

What I’m missing in you article is a naming convention for class names. I usually use hyphened class names like .some-class as everything else in CSS is lowercase. I imagine you and other people would have different approaches to this

What I also do is to include a snippet of comments at the beginning of each stylesheet which gives an overview of what the stylesheet is about and a brief table of contents with keyword searchability to different sections.

What i also do is to keep a naming convention consistent throughout the html, css and javascript so that i know what belongs to what.

Oh and thats 2,000 liner, yeah I remember that so don’t bring back memories.

With regards to IE hacks. I never include any in the main stylesheet. All IE hacks, filters and work arounds are in a separate stylesheet which again is a for long term maintenance.

What I have also started to do on projects where IE6 is not needing support is to follow a Object orientated approach to CSS, so extending any components with addition of class and necessary styles / js (Moo FTW!). Nicole sullivan has some great tips on how to do just that so google is your friend.

Thats it from me. Great article and nice to see how other developers approach this.

And i use my ie css hacks (i try to make them smallest as possible) on the same file because its easier to maintain. I mean if you have to change something after the site has been deployed you’ll change the original css but for sure will forget the ie hack file.

But nowadays im ust using hacks for png transparency (most of the times), which i keep on a different file.

My only die-hard rule for css is separate files for each “component”. If you can get people to agree with that one then the rest is a non-issue.

I highly recommend CSSEdit.app on the Mac. Very very nice for quickly getting stuff done. Especially new projects.

Here are my rules…

* Small focused separate css files. Compiled into a single compressed file using a build script for production mode only.

* Never Indent anything but properties.

* Never commit single-line rules. (as the maintainer of the CSS.tmbundle I’ve added a number of tools to quickly reformat your selection, might be in experimental on my github only)

* Always reformat all sheets as a separate commit before beginning anything new on an existing project. (for some reason clients go nuts for this simple reformatting

* Sort properties in logical groups when hand coding. TRBL sorting. When using CSSEdit I just let it do what it does.

* Prefer separate IE css, but also mix only very stable IE hacks into my main CSS file. I’ve tried keeping them separate but it becomes a maintenance issue.

* Use CSSEdit Groups to keep things separate when separate files aren’t possible.