When you’re starting a new web site and it comes time to start thinking about CSS, the first thing you should consider is picking a framework.
Using a CSS framework isn’t a requirement of any project, but it’s a very good idea, because it makes your code much more maintainable. It’s OK to use your own style along the way, but starting from scratch is not only very challenging, it’s also very time consuming, even for smaller projects. A framework gives you reset code, helper classes, and a whole multitude of useful stuff. I prefer using Blueprint, but there are lots of other frameworks out there to choose from.
A framework is a good starting point, but there’s very little chance that it will have everything you need. In your own CSS file, you can build your own styles on top of the framework. Before you start building your own styles though, take some time to familiarize yourself with the framework you’ve chosen. That way, you’ll be aware of some of the features available to you so that you don’t end up recreating code that’s already ready to use.
After you’ve chosen a framework, the next step is to set some coding conventions. This is especially important if you’re working on a project with others or on a project that you’ll want to revisit in the future.
If you’re working on code with a team, or even if you’re working by yourself, you should set some guidelines for code style before you get rolling. That way, your CSS will stay more organized, and you’ll be able to make additions to the project in the future, if necessary.
There are some tedious things such as how many line breaks you want between each selector, how many spaces you should indent and what tab style to use. For example, in TextMate or whatever text editor I’m using, I like my tabs to be 2 soft spaces. However, this is just subject to personal taste.
You can also add a lot of readability to your files by including helpful comments. One particular type of comment, called a flag. A flag is usually about 3 lines long. The first line is a row of some symbol, like stars or dashes, the 2nd line is a label, and the last line is another row of symbols. Flags are nice because they improve the scanability of your code and can help you find large chunks of CSS more quickly.
Lastly, the most important thing here, is to stay consistent. There’s all sorts of coding styles for CSS and there are no standards. You should look at other people’s code to get ideas, but experiment and decide what’s best for you. Once you start a project coding a certain way though, make sure to stick to it.
After you’ve set some coding conventions, you should spend some time thinking about how you want to organize your actual CSS files.
Everyone has worked on a project where there’s a single CSS file that’s over 3,000 lines long. This might work for some people, but the majority of designers and developers will get lost in something like that very quickly. If any one CSS file in your project is getting too long for you to keep track of, it’s best to split it out into separate style sheets.
One way to organize your stylesheets is to name them according to what each stylesheet does. For example, you might have a stylesheet that resets the browser styles, and you might have another stylesheet that’s specifically for styling web forms. If you want to get even more granular and you’re working on a large scale project in Rails or some other model-view-controller framework, you might want to have a few global stylesheets, and then a stylesheet for each individual view to address any areas that need special styling.
Again, just as is the case with coding conventions, you should pick some file conventions and stick to them.
There’s a ton more to learn about organizing CSS, but the most important thing to remember is that you should break old habits every now and then so you can find out what works best for you.