CSS Style Guides

As we wrap up our recent poll on ordering CSS properties, it brings up the larger issue of CSS style guides. Ordering properties is just one choice you have to make that makes up a complete styling strategy. Naming is a part of it. Sectioning is a part of it. Commenting, indentation, overall file structure... it all makes up a complete CSS style guide.
Let's round up some existing ones.

But first... Not Pattern Libraries.

I love pattern libraries. Think Twitter Bootstrap or GEL. I think they are a fantastic way to work particularly in large sites and web apps. This post isn't about those. We'll do a roundup of those some time, because I think that would be valuable too. This is about style guides for CSS itself.

The List

I'll list some excerpts from each that I like below.

GitHub


GitHub CSS Style Guide →
As a rule of thumb, don't nest further than 3 levels deep. If you find yourself going further, think about reorganizing your rules (either the specificity needed, or the layout of the nesting).
Unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.

Google


Use ID and class names that are as short as possible but as long as necessary.
E.g. #nav not #navigation, .author not .atr
Do not concatenate words and abbreviations in selectors by any characters (including none at all) other than hyphens, in order to improve understanding and scannability.
E.g. .demo-image not .demoimage or .demo_image

Idiomatic CSS


Nicolas Gallagher's Idiomatic CSS →
Configure your editor to "show invisibles". This will allow you to eliminate end of line whitespace, eliminate unintended blank line whitespace, and avoid polluting commits.
Long, comma-separated property values - such as collections of gradients or shadows - can be arranged across multiple lines in an effort to improve readability and produce more useful diffs.
Use separate files (concatenated by a build step) to help break up code for distinct components.

CSS Wizardry


Harry Robert's CSS Style →
I have a blanket-ban on IDs in CSS. There is literally no point in them, and they only ever cause harm.
This section heading is also prepended with a $. This is so that—when I do a find for a section—I actually do a find for $MAIN and not MAIN.
In situations where it would be useful for a developer to know exactly how a chunk of CSS applies to some HTML, I often include a snippet of HTML in a CSS comment.

Smashing Magazine


Vitaly Friedman's "Improving Code Readability With CSS Styleguides" →
For large projects or large development team it is also useful to have a brief update log.
For better overview of your code you might consider using one-liners for brief fragments of code.

ThinkUp


ThinkUp CSS Style Guide →
If the value of the width or height is 0, do not specify units.
Comments that refer to selector blocks should be on a separate line immediately before the block to which they refer.

More?

Does your organization maintain and use a public style guide? Post it!
CSS Style Guides is a post from CSS-Tricks