Typically you will be able to break your css into manageable sections, this will involve a number of global helper classes and then more specific classes for particular areas of content, this should be reflected in your organization. I would typically break your code up as follows and include it in the cascade in this order.
- Global Resets, there are many already available to help make browsers consistent.
- Default tag styles, e.g for headers and links.
- Global helpers, e.g. a box class, which applies global box styling and also commonly required rules such as needing overflow: hidden, to for float clearance. Other classes can then subscribe, as required.
- Library styles, you may have css to support library code such as forms and datepickers.
- Page structure, e.g. navigation, headers and footers.
- Components, similar to library code, however these will be the specific components for the current project.
- Overrides, e.g. for particular pages, or for a differently skinned area.
To avoid one massive file, these should be separated into corresponding files, and even further separated into sub sections if required. Although they should be concatenated and compressed for your production release.
Commenting Your CSS
This is probably less of an issue with css than with programming languages, because if you know css it’s should a simple case of looking at the rules that are applied, also with tools such as firebug, using the inspect view, you should be able to figure out what’s happening a lot easier than any comments. Having said that if you have done something which may seem unusual, or not required, for example if you are including a fix for IE then a comment is essential.
Another good use of comment is outlined in this article on dezinerfolio, as most people prefer to keep there css spread over only a few files, you should including indexing and grouping to make different sections of your site clear.
/*== INDEX ======================= $__header Header definitions $__menu Global navigation --------------------------------------------------------------------------*/ /* __header --------------------------------------------------------------------------*/ /* __menu --------------------------------------------------------------------------*/
This I think is a nice way to clearly find your way around and get an idea of the different areas of the website. The same article has another suggestion, which suggests you include version numbers, author names and other meta data, I personally don’t see the need for this as, it should already be covered by the version control system (such as SVN), which I assume every sensible developer is using, and so including it will just give you something extra to maintain. More things to maintain equals less maintainable.
Code Formatting
A good list of css formatting options can be found at perishablepress
From a maintenance point of view it breaks down into 3 contenders,
New line after each rule, clean and readable, and version control is able to point out the exact rule that has been changed.
.example-01 {
padding: 1px;
margin: 11px;
width: 111px;
}
All rules on one line with their selector, easier to group things into sections, highlights the selectors. Readable, as long as you don’t have too many rules.
.example-01 {padding: 1px; margin: 11px; width: 111px}
Using indentation to highlight code structure,
.example-01 {padding: 1px; margin: 11px; width: 111px}
.example-01-sub {padding: 1px; margin: 11px; width: 111px}
.example-01-sub-sub {padding: 1px; margin: 11px; width: 111px}
The latter option seems at first interesting as it gives an indented structure to the css similar to what you might find in a full programming language. However it is a bad idea, as it couples your code to the mark up and is likely to get out of sync with the mark up. As I said before more things to maintain is less maintainable. I’m more torn between the other options, as I find putting all the rules on one line is more readable, and makes the different css components better defined. However you do end up with side scroll and render your version control less useful. It wouldn’t kill me to find either format used in a project.
One other suggestion I’ve seen is to list each rule alphabetically, but I really don’t like this, sounds like another needless thing to think about and maintain, and I can usually find the rule I want fairly quickly, so personally I don’t see the advantage.
In addition to following organizational guidelines, there are a number of rules to follow and pitfalls to avoid when it comes to building your css and your pages in general, which I’ll cover in another entry.