Keep your CSS in order, for your own good

Commenting and titling your code may seem superfluous to a beginner, but sure like taxes if you keep going designing website you will have to come back to old projects. More than that, when other designers open your code, necessarily they need to understand what you did and how. Perhaps also why. The sooner you’ll tune your syntax, the more you’ll get out of it. So, better start now!

When I switched from Actionscript and Flash websites, to a pure HTML/CSS structure it was quite an enlightenment. Learning more and more how to give shape to a pure semantics was source of great gratification.

If I open today a CSS file that I realized years ago, I barely recognize my hand in it. Indeed, even the way I was used to write styles in CSS last Winter wasn’t that cool. The worst aspect of this it’s that if I have to come back to old projects to just modify few details, I’ve first to decipher why I did what, and the operation risks to become quite time consuming.

I decided to take a more professional approach and I’m so glad I did! Commenting your code and keep the various files of which it’s composed in a good order it’s a very basic thing in programming. Same for the CSS files.

It’s also a good practice and a form of respect for whom who, one day, will have eventually to open our files and do things. If we ourselves find our own code confusing, how would an other web designer deal with it?

So, here the way I do.

Split in Modules

First thing, I wanna be able to re-utilize my code faster each time I start a new project. It’s annoying to copy and paste snippets inspecting a never ending list of rules. Better have different “drawers” and knowing that your fresh underwear are always in the first one from the top. Isn’t it?

• style.css
• development.css
• ie6-fix.css
• ie7-fix.css
• my960.css
• plugins.css
• reset.css
• typography.css

You may not need to implement the same approach but it’s a good idea to store different parts of your styles in different files. It makes easier to get what you need and just that.

Anyway, here I explain what I put in what.

Style

It’s the main CSS file. From here I import all the others. It contains the styles for that particular theme or website. It can override particular rules, like the standard typography initialized in typography.css.

Development

Specially at the very beginning of the designing process of a new layout it’s helpful to be able to switch quickly to a development setup of rules. Mainly mine contains only two rules.

html {
	background: transparent url(grids/960-grid-12-col.gif) repeat-y center top!important;
	opacity: 1 !important;
}

html body {
	opacity: 0.9 !important;
}

When I need to fix columns and stuffs I display the grid I’m using (in this example a grid 960 pixels wide composed by 12 columns) giving to everything after the body an opacity less than 100%. This way I can see through all the elements in page, till the bottom grid, so that the minimal misalignment becomes clear. Keeping those rules in a separated file allows me to switch them on and off quickly and to skip them totally once the design is complete.

A couple of pictures will make it clear.

ie6-fix and ie7-fix

Some browsers really need fixes. I keep the rules for each browser in a proper CSS file to be imported only for one particular browser. Nothing really new here.

my960

I use intensively the 960 grid system and I modified it a little bit to fit more my needs. This file contains all the rules for the grid, simple as that.

Plugins

Time to time I need to re-style a plugin or add-ons. I don’t mix up my styles with the plugin‘s styles. I prefer to have a repository of rules to target specific aspects of the output of those add-ons. If I need the same plugin in a new website or theme I can then come back to a previous project that use it and steal few lines from that file, tuning at will. This way I don’t have to investigate CSS from other designers a second time: I’ve already handles to act precisely.

Reset

Resetting plain differences among different browsers is a common practice. I keep those rules in a proper file mainly ‘cos it does not change very often.

Typography

Oh, well, this’s cool. I finally developed my typographic styles and I use them as fundamental for new projects. I can switch to one or an other typographic base very quickly editing a couple of line of this file. Some of these rules will be then over written by the style.css file, so I keep my typography.css quite constant from project to project.

The Library

To keep all those files ordered I put them in a proper folder, and I call it library. Inside I usually create other folders for scripts, web fonts and CSS files.

Occasionally I keep into that folder also images and icons to be displayed via CSS.

Importing

Once we have everything in place we need to make use of it. I use two main methods. First I need to link the style.css to the HTML. If I’m working with WordPress this line has typically to be located in the header.php file.

In the HTML

<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" />

Second step, in style.css we need to import the basic rules starting with the reset.css. Then the grid and the typography.

In the style.css file

@import "library/styles/reset.css";
@import "library/styles/my960.css";
@import "library/styles/typography.css";

What we import with this method will be easily over written by rules later declared in the same file.

Back to header.php, occasionally I need to switch on the developing mode. So I link this CSS file at the end. Same way for the plugins.css file. Declaring those rules at the end makes it simpler to overwrite previous rules from other CSS sections. This example is from a header.php file in WordPress.

Overwriting previous rules (again, in the HTML)

<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_directory' ); ?>/library/styles/plugins.css" />
<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_directory' ); ?>/library/styles/development.css" />

If you work in WordPress those two lines and similar should to be located after the hook wp_head, because several plugins (or themes) insert styles using precisely that hook.

Commenting and indexing

The whole list of rules that styles a whole website can be quite long and definitely overwhelming in the absence of any support. Putting our hands into old projects after some time may be confusing. Learning how to properly comment your code is critical and really saves time.

At the top of each file I write a short description of what it does and what it contains. Notes to be remembered and, this’s very important to me, an index for a quick overview.

/*---------------------------------------*/
/*	Title of the project // File name */
/*---------------------------------------*//*

	NOTES
	Lorem Ipsum is simply dummy text 
	of the printing and typesetting industry.

	0.0	Reset and importing  
	1.0	General rules
	1.1	Typography
	1.2	CSS3 Animations
	1.3	Titling
	1.4	Special pages
	2.0	Header
	3.0	Menus
	4.0	Contents
	4.1	Comments
	5.0	Sidebars
	6.0	Adv
	7.0	Footer	*/

/*---------------------------------------*/
/*	0.0	Reset and importing	*/
/*---------------------------------------*/

@import "library/styles/reset.css";
@import "library/styles/my960.css";
@import "library/styles/typography.css";


/*---------------------------------------*/
/*	1.0	General rules	*/
/*---------------------------------------*/

body {
	background-color: #fff;
	background: transparent url(images/bg-paper.gif) repeat;
}

#wrapper {
	margin: 0 auto;
	padding: 0;
}

/* ...and so on... */

That’s just a example. You may have a different way to save details about your projects and to comment the code. But the point is: keep it clear!

Main classes and id

Websites usually have few treats in common. Some kind of classes and id are sort of standard and their use it’s basically unavoidable. It’s a good practice developing your own main structure and keep it as your standard from project to project. For a classic WordPress theme I would often start using the following rules.

• body
• #wrapper
• #header
• #menu, .menu, .nav
• #container
• #comments
• #sidebar or .sidebar
• #footer
• .post

I keep all of those in the General Rules section so that to have a sort of control room from where I can apply main changes to the design. Remember that in order to validate your HTML, there should be no more than one element with a particular id in a page, while classes can be used freely to target multiple elements in the same page. Keep this in mind to simplify your code.

Main structure

That said, it makes sense to me to style sections of the website in the order they appear on page. At the very beginning of a new project I use a simple template of the style.css file, and I fill it up on the way. This provides me a schedule or a check list through which to proceed.

Apart for the notes and other description of the file on top, my main structure is very similar to the one below.

/*-----------------------------------------*//*

	0.0	Reset and importing  
	1.0	General rules
	1.1	Typography
	2.0	Header
	3.0	Menus
	4.0	Contents
	5.0	Sidebars
	6.0	Footer	*/



/*-----------------------------------------*/
/*	0.0	Reset and importing	*/
/*-----------------------------------------*/

@import "library/styles/reset.css";
@import "library/styles/my960.css";
@import "library/styles/typography.css";


/*-----------------------------------------*/
/*	1.0	General rules	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	1.1	Typography	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	2.0	Header	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	3.0	Menus	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	4.0	Contents	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	5.0 Sidebars	*/
/*-----------------------------------------*/

/*-----------------------------------------*/
/*	6.0	Footer	*/
/*-----------------------------------------*/

Titling

To let your eyes pass safely through thousand lines of rules, you need to make each section clear and easily recognizable. There are several ways to title sections and to comment. Let’s see few examples I found while analyzing third parties CSS.

/*----------------------------------*/
/*	Title	*/
/*----------------------------------*/


/* Title
------------------------------------*/


/* Title */


/* Title ////////////////////////// */

Well, that aspect is not that critical, it just has to be clear for you and for others designers when they will need to read your code.

In the end…

Commenting and titling your code may seem superfluous to a beginner, but sure like taxes if you keep going designing website you will have to come back to old projects. More than that, when other designers open your code, necessarily they need to understand what you did and how. Perhaps also why.

In the end, packing an excellent syntax, you will give a so much better impression as professional! Learning how to keep your styles in order is just too good to miss it.

Feel free to comment the article and get back to me with suggestions or corrections. And thanks for reading!