Here’s one my files: http://onioneye.com/themes/echo/wp-content/themes/echo/style.css

As much as the alphabetizing makes sense, it’s not ideal. It makes more sense to have a certain order to the properties, like first is position, than margin/padding, than text styling (font, text alignment, etc.), background, and lastly is borders (mostly due to CSS3 taking up a lot of space at the moment.

Great article, here’s one of my CSS files http://cdn.myunv.com/css/uecore.css

Great article!

P.s. With a name like Radu you must be Romanian! NOROC!

Single line code is good for small websites but if you are coding a wordpress theme, things will go little messy.

Back on subject, which remains a ‘hot’ topic, I see the indenting good only in html and not necessary in css. If you cleverly indent and tag in html, the contextual selectors do the same in css. When I see “#header h1″ in css I know there’s a with a inside it.
To conclude my point of view let’s assume an exaggerated parallel: that we can write a musical score in the same way we write css. Now, how will you play by an “over-achiever approach” score?
Great posts! Keep’em coming!

@DesignInformer: exactly; it’s about what works for you and your team and the project at hand.

@Anthony Hortin: you’re a god amongst programmers then, and we salute you wholeheartedly.

@MCB Web Design: I agree, and as I’ve pointed out at the beginning of the post, if you really need to, you can use a minifier.

@Takingweb: thanks for the fav! I try not to think of them as guidelines as much as construction blocks. You build the structure your project needs using the blocks that serve your purpose best. Yeah, I like metaphores, ok?

@Igniatovic Nikola: I ran into the same problem time and time again. Sometimes I’d give in to their single-line-ess, but other times I would push for multi-line. In time I’ve learned that it’s not what I fancy that matters, but what’s best for the project. And what’s best for the project is best for us, right?

@sajjadul farooque robin: YSlow is kind of a weird tool, if you don’t configure it a bit. You can set what kind of project you’re working on, and depending on that, it will adjust it’s limits. For example, on a blog, multiple CSS files pass ok.

@Alfredo Matos: Good point. That’s a bonus for keeping the bracket on the next line. Thanks!

@Julian Nicholls: I’ve seen this approach a few times with other designers but have always found the combination a bit distracting and hard to skim. It’s a good tip, though, for anyone that has no trouble reading this system.

@Niels Matthijs: as far as I know, not all code editors have an option to color code subjectively, so your tip, although valid, is only applicable to some editors. I can see where you’re coming from. There seems to be a kind of psychological delight to scrolling through hundreds of lines of code. Hey, I’m guilty too! Some people don’t find multiple files cumbersome. In fact, if you keep all of them opened (and most of the time there are about 3 files) you can easily switch with a keyboard shortcut. Thanks for the tips on the comments usability, I’ll take them into consideration! The post button problem was probably at your end, since it’s peachy fine for everyone else. Perhaps the page didn’t load fully. Browsers, right?

@Henrik Kjelsberg: I agree, most of the time, something like the over-achiever approach doesn’t pose any problems (plus, it can look pretty impressive right?) but when you’re dealing with a large project that has a short deadline, every second spent formatting code just for the sake of it looking pretty is time wasted.

@Thomas Craig Consulting: it’s an interesting idea but I’m not sure what the upper limit for CSS overwrites is until browsers start to become a bit sluggish on page load. I was talking to a programmer friend just today about this. It’s unclear how browsers perform when you’re overwriting say 200 selectors or maybe overwriting 10 selectors 20 times, for example. Of course a lot of factors come in, but I guess it’s something to think about.

@Duncan Beattie: good approach! I bet most of the time this saves a lot of time on updates. But what do you do when the client demands structural changes? As far as I know, a un-minifier has yet to be invented

@Zach Schneider: of course comments are always a good idea, no matter what language you’re writing in. I don’t care if you write in C# or HTML or friggin COBOL (that’s a joke, guys), comments are a must. But comments have nothing to do with formatting your styles. Comments, to me, have to follow the CSS format of choice, not influence it.

@Thom Lohman: javascript without identation is, for me as well, like looking for a needle in a haystack. A big, messy, strange haystack. Eliminating the linebreaks is a good idea if you keep the ending bracket on the next line; that way you save space and don’t have to worry about deleting it when getting rid of the last attribute and property, like Alfredo Matos mentioned below.

@Zoran Jambor: hey, everybody! we’ve go one of “those guys” here just kidding. But, seriously, how do you read through it? Come clean, are you a Firebug freak?

@Marco Pivetta: as I said in the post, “the downtime caused by large CSS files is, mostly, insignificant.” so, there wasn’t really an argument there, it was a consideration point for all those that are overly concerned with file sizes. So, yeah, I agree it’s all about editing faster, easier and better.

@Aaron Blakeley: I think most of us like to read through our stylesheets like a story, because, as designer, we are, in a way, telling a story. It’s a beautiful metaphor and I equally congratulate you for it and despise you for thinking of it before I did. Sarcasm +1 for me

@Elf M. Sternberg: Cool, Aaron started as a designer and went into programming, you started as a programmer and moved into design. How poetic! LessCSS is, indeed, an interesing solution, but the fact that it implies programming sticking it’s fingers in styling is a downer for most web designers. But for your background in programming, it must feel right at home, no?

@Neil Monroe: I don’t know about you, but I find the whole “deployment” issue quite the nuissance 90% of projects. Sure, the really huge web apps that lean on every extra kilobyte do benefit from this approach, but most of the time, it’s just overkill as you’re not really lowering the page load times noticeably.

@Jasper: Thanks, apprently I don’t suck that bad Jasper…meet Elf (he commented below). He uses LessCSS too. Be friends And another Sarcasm +1 for me.

Just for the record: I’m not proclaiming to know the perfect way to format your CSS, the point of the article was to break down a set of decisions which you can mix’n'match specifically for your projects. I’m a ferm non-believer in a fool-proof, universal, perfect way to format CSS.
That being said, my way is the perfect way

A very intuitive way to write CSS is LessCSS ( http://www.lesscss.org )
It’s a pity it removes comments in the final css file, but it’s still great!

However, I also agree with MCB Web Design about not using CSS minification until project deployment. Your code should be as easy to read when developing. Don’t worry about spaces or newlines. These can all be removed when you’re ready for production.

Combining all the CSS files together as one before minifying is a good idea to help keep the number of requests lower.

Adding good commenting to your CSS code is a must for me, too. It helps a lot when quickly browsing through a long CSS file. Comments can all be removed with a minifyer as well.

CSS frustrates programmers because it’s completely flat: every description describes a single kind of element, whereas HTML is containerized, and may contain many kinds of elements. LessCSS makes CSS conceptually resemble your HTML, and that makes it so much better.