CSS Style Guides

Avatar of Chris Coyier
Chris Coyier on (Updated on )

📣 Freelancers, Developers, and Part-Time Agency Owners: Kickstart Your Own Digital Agency with UACADEMY Launch by UGURUS 📣

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

Google HTML/CSS Style Guide →

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.

WordPress

WordPress CSS Coding Standards →

Add two blank lines between sections and one blank line between blocks in a section.

Broad selectors allow us to be efficient, yet can have adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead to a cluttered stylesheet. Exercise your best judgement.

Magic Numbers are unlucky. These are numbers that are used as quick fixes on a one-off basis. Example: .box { margin-top: 37px }.

SMACSS

Jonathan Snook’s Scalable and Modular Architecture for CSS →

This thing is a beast and it would be hard to pull just a few quotes. But…

Throwing every new style you create onto the end of a single file would make finding things more difficult and would be very confusing for anybody else working on the project.

If done right, Modules can easily be moved to different parts of the layout without breaking.

Only include a selector that includes semantics. A span or div holds none. A heading has some. A class defined on an element has plenty.

More?

Does your organization maintain and use a public style guide? Post it!