CSS coding standards

Well, it’s now 2010 and as usual, January brings with it many self-made promises and resolutions, one of mine is to write more, even if it’s just quick tips & tricks rather than lengthy diatribes which I always want to write, but never seem to find the time.

During the back end of last year I started to experiment with one of the more boring aspects of CSS, but one of the most rewarding in the long-term: How I actually write, organise and maintain my CSS files. These are relatively minor tweaks, but I thought I’d share them in case anyone finds them useful.

I’d just like to note that these are my personal preferences, you may disagree entirely with the way I do things and that’s fine, feel free to drop a comment below if you’d like!

Single vs. Multi-line

So lets get this out of the way, I hate single line CSS rules, they’re a pain-in-the-ass to navigate and can cause problems with some source control tools which may only tell you which line has changed and not which property has changed specifically or when running your code through the validator and getting errors which refer to specific line numbers as well as times when you might not have syntax highlighting to help you quickly visually identify properties and values (such as viewing CSS in Firebug).

I’ve never written my CSS rules as single-line and I doubt I’ll ever start.

Ordering of declarations

One of my most common bugbears is with the ordering of declarations, a lot of the CSS files I come across in my ‘day job’ are simply not ordered in any meaningful way, some have a semblance of ordering based on the personal preferences of the designer and may have width & height rules together, floats and positions together for example, this always differs from designer to designer.

The best way to order declarations is alphabetically, it makes it far easier to scan through and visually locate a specific declaration, especially in large rules. Also, for teams of multiple designers it’s far easier to add declarations to an existing rule as they simply slot in alphabetically.

1
2
3
4
5
6
7
8
9
10
ul#nav_primary li a {
    border:0;
    color:#999;
    display:block;
    float:left;
    font-size:1.2em;
    font-weight:bold;
    padding:010px;
    text-decoration:none;
    text-transform:uppercase;}
### Curly braces

This might be one of those decisions where people think “Does that really matter?”, but I’ve started to place my closing brace on the same line as the last declaration. The reason behind this is to improve the visual distinction between rules which helps when scanning quickly through a large CSS document.

Previously, I’d place the closing brace on it’s own line, like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
h1 {
    border-bottom:2pxsolid#ccc;
    font-size:2em;
    line-height:1.5em;
    margin:0018px0;
}
h2 {
    font-size:1.333em;
    line-height:1.125em;
    margin:1.125em0;
}
h3 {
    font-size:1.1667em;
    line-height:1.2857em;
    margin:1.2857em0;
}
Now that the brace follows the last declaration it improves the spacing between rules, or course I could simply add another line after each rule, but that simply adds to the filesize and needlessly pads out the document. This method also places all of the selectors on their own tab level which helps when scanning through to locate a selector.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
h1 {
    border-bottom:2pxsolid#ccc;
    font-size:2em;
    line-height:1.5em;
    margin:0018px0;}

h2 {
    font-size:1.333em;
    line-height:1.125em;
    margin:1.125em0;}

h3 {
    font-size:1.1667em;
    line-height:1.2857em;
    margin:1.2857em0;}

### Closing semi-colon

The closing semi-colon on the last declaration of a CSS rule is optional, while some people will no-doubt argue that dropping this will lead to smaller filesizes I’d always argue that long-term maintainability is more important, especially on larger projects with multiple developers or for projects which are handed to clients to maintain themselves.

By keeping the closing semi-colon in place anyone can quickly dive into the file and add rules without needing to worry about where the semi-colons are.

Further reading

I’ve only skimmed the surface of CSS coding standards to highlight some of the ways I like to do things, If you’re interested in making your CSS more readable, and especially more maintainable then I’d highly recommend you read the PDF version of this BarCamp presentation by Natalie Downe on “CSS Systems for writing maintainable CSS” which is a must-read and chock-full of excellent advice.

What do you do?

Do you have any personal preferences when it comes to writing your CSS? Feel free to hit the comment box below and let me know!

comments powered by Disqus