In any sort of collaborative context, especially when it comes to code and the Web, following a standard is important. As such, in order that my CSS files are descriptive and legible to others as well as to myself, I follow a set of conventions in each new document that I create.
Note that while some Web developers prefer to rely on their development software to format their style sheets, I do all this by hand (i.e., I type the code directly as opposed to manipulating it through a GUI).
Filename
The first thing to consider is naming your style sheet appropriately. I always name my main style sheet baseline.css, because it serves as the style sheet from which I can build more specialized styles (e.g., a print version of the site). Where I need a style sheet for a particular media type such as print or projection, I use the name of the medium, giving us print.css and projection.css respectively. More often than not, I also want to include a separate style sheet for Internet Explorer that I serve through conditional comments. I name this file ie.css, or if I’m targeting a particular version, I include the version number (e.g., ie6.css).
The Header
At the top of every style sheet that I create, I make sure to describe the file’s context. I use a template that I keep whenever I start a new CSS file:
/*
author: [my name and URL]
project: [the URL of the site I'm working on]
scope: [where the style sheet applies (usually "site-wide")]
*/
You can get as detailed as you see fit for the scale and needs of the project you are working on. For instance, I might want to denote a version number with version: 1.2. What I’ve included above is the bare minimum.
Aside from being useful to others working on the same project or someone simply taking a look at your source, I find this information invaluable when, for example, I’m looking through a bunch of files on my computer called baseline.css and I need to find the one that corresponds to example.com. In general, the more documentation you provide with your code, the better.
Structure
Especially on bigger projects, keeping the body of your style sheet organized is a must. I always break the body down into sections and I employ easy-to-see headings to mark each section I make. Here is the style I use, but of course, the format is up to you:
/* THIS IS A HEADING
***************************************************/
As for what I find useful in terms of making divisions, it depends somewhat on the project, but I usually have at very least the following sections:
- ELEMENT DEFAULTS
- LAYOUT LOGIC
- PAGE-SPECIFIC
Item (1) is where I put all of the rules for plain old HTML elements such as p {...}. Item (2) describes the way that pages are laid out. This section contains rules pertaining to structural elements that are common to multiple pages. Item (3) contains rules pertaining to the content of specific pages. I like to keep this separate in order to avoid clutter in the rest of the style sheet. For the most part, the sections move from more general rules to more specific ones. On larger projects where I divide the body of my style sheet into many sections, I even include a table of contents.
Rules
The following is an example of a rule with only one property. I like to keep these on one line:
p { line-height: 1.5em; }
When I have a rule where I’m setting multiple properties, I break it up over separate lines:
p {
line-height: 1.5em;
font-style: italic;
}
Note that the only part not indented is the selector, so that you can easily scan the document with your eyes for a particular element or class in the same way that bibliographies are indented so that you can scan the left margin for an author. Where I am grouping multiple selectors, I like to keep them on separate lines for this purpose:
p,
li { line-height: 1.5em; }
Note also that I always include the semicolon following the last declaration in my rule, so that if I add a new declaration, I don’t need to worry about what’s already there.
This particular format is just a suggestion. Your own style may vary according to your preferences as long as it is legible and consistent.