One of the nice things about languages like CSS is that you don’t have to write them in any specific way. For example, you could place all the CSS rules for your entire website on a single line of text, and assuming you had some brackets and semicolons stuck in there at appropriate intervals, your website would render without a hitch.
Of course, finding a single, specific rule in that amalgam of CSS soup would be a bit difficult, and that starts to negate the benefits of using CSS in the first place. Luckily, we have the opportunity to use the flexibility inherent in writing CSS for good instead of evil (or at least preparedness instead of poor planning). Here are a few tips that can make your CSS much easier to read – and therefore edit – in the long run.
Pick a Formatting Style
When I’m writing example CSS for someone to follow, I tend to use a more traditional formatting for my rules, like so:
body {
font-size: small;
color: #333;
}
p {
margin: 1em 0;
}
However, for all its ubiquity, I don’t really care for this style. My eye tends to get distracted by the closing bracket on a line all by itself, and I consider it a bit wasteful to spend an entire line to say, “Okay, I’m done now,” when CSS lets us put that bracket wherever we darn well please. So when I write CSS for my own projects, I write it like this:
body {
font-size: small;
color: #333;}
p {
margin: 1em 0;}
The only real change here is that I’ve moved the closing brackets up to the preceding line, but it helps me a lot. Now my eye knows that anything in the far left is a selector, and anything indented is a property. I’ve also saved myself two lines of code. Now, I’m not saying this style is right for everyone, but the main idea here is to find a style that works well for you and stick with it. Once your eye gets used to seeing your CSS written in a specific way, scanning your code gets a lot easier.
Section Your Code
CSS has built-in comment tags, which look like this:
/* This is a comment! */
p {
margin: 1em 0;}
Anything that appears before the opening comment tag and the closing tag, no matter how many lines it spans, is considered a comment. These little tags are great for putting up little notes to define sections of your code. I personally use comments as heading tags to define sections of my website. For example, I might have one section titled /* Sidebar */, where I put all of my sidebar-related styles, or one called /* Article */, where all my article-specific CSS resides.
You can get as general or as granular as you want or need with this technique, depending on the size and complexity of your stylesheet. If I’m the only one who’s ever likely to edit the CSS, I tend to get away with fewer comment tags than I would if I knew that other people would be trying to decipher my code.
Use a Table of Contents
If you end up creating a massively large and complex stylesheet, containing several hundred or even a couple thousand lines of code, simply breaking that code up into a dozen or so sections might not be enough. On my biggest projects, I tend to create a Table of Contents at the top of my CSS to help me remember how my CSS is organized, and help me (or someone else) find things later on down the line. A table of contents might look something like this:
/* Table of Contents:
1. Reset Styles
2. Baseline (Default) Styles
3. Column Structure
4. Main Column (articles, etc)
5. Comments and Pingbacks
6. Sidebar lists and Ads
7. Footer
*/
Then you can just insert appropriately named comment headings along the way to help you or someone else make their way through your document. Scanning code gets a lot easier when you know you’re looking for section #5 and that there will be a comment tag to let you know when you’ve arrived.
Group Selectors with Common Values
Let’s say you have five levels of heading tags in your articles, h1 – h5. They are all rendered in Verdana, but at different sizes and colors. Obviously, you’re going to need more than once rule to style all these elements, but that isn’t to say you can’t group their common attributes together. For example, instead of writing this:
h1 {
font-family: Verdana, sans-serif;
font-size: 200%; }
h2 {
font-family: Verdana, sans-serif;
font-size: 175%;
color: #333; }
h3 {
font-family: Verdana, sans-serif;
font-size: 150%;
color: #f00; }
/* And so on… */
You could make everything a lot cleaner and easier to edit in the future by writing this instead:
h1, h2, h3, h4, h5, h6 {
font-family: Verdana, sans-serif; }
h1 {
font-size: 200%; }
h2 {
font-size: 175%;
color: #333; }
h3 {
font-size: 150%;
color: #f00; }
/* And so on… */
Group Default Styles
Mike Rundle of BusinessLogs recently argued that using default styles (for example, styling all your anchor tags at once) is counter-productive, because when an element isn’t behaving like you’d expect it to later on down the line, you can spend a lot of time trying to “fix” your code unnecessarily because you’ve forgotten about a default style you’d set previously.
I agree to a point: I would say that you shouldn’t overly style general elements. Don’t style your anchors as bright red with a dotted border unless 99% of your links are going to appear that way. However, if none of your links in your entire site are going to have an underline, I don’t see the harm in removing the underline from your anchor tags. Because here’s the important thing to remember: all browsers have a default style sheet. Even if you don’t apply a single style to your anchor tags, they’re going to have a style (blue, underlined) to begin with. Using default styles is a means of establishing a baseline more conducive to your overall site goals.
But you can make your life a little easier by grouping all of your default styles. I tend to put them all up at the top of my document, labeled with a comment-header. That way, if (to continue the example) my anchor tags aren’t behaving like I expected a few hundred lines of CSS later, I can just check really quick to make sure my default styles aren’t interfering in some unexpected way (but since they’re only baseline styles, that’s rarely the case).
These are just five tips that have helped me keep my CSS a bit more organized. Do you have any tips that have helped you streamline your CSS?