Skip navigation

Tag Archives: optimised

CSS has reached a level of maturity now where it’s safe to use in a cross-browser environment. Gone are the days of maintaining reams and reams of presentational markup – That’s hard work. CSS is all about working smart.

Working with someone else’s CSS can be a little tedious. Rules all over the place. And in what order? Finding matching rules used to be a complete pain before FireBug came out. (Have I mentioned before just how useful FireBug is?)

There are a few things you can do to make your CSS more readable for others and yourself.

It all starts with dividing your CSS up into at least 3 sections.


A Section for General Rules

First, start off your CSS with a section dedicated to general rules. Ambigious rules. Set the colours of your links, contrasting background colours, your default font sizes, etc.

/* =============================== *\
|  General                          |
\* =============================== */

a:link {}
a:visited {}
a:hover {}
a:active {}

a img {border:0;}
.aural {display:block; position:absolute; top:0; left:-999em;} /* Off-left technique */

If you’re using a resetting CSS, you might want to skip the above step and replace it with an @import rule instead.


A section for your Document Tree

The next section is your homage to your HTML. (Without rocksteady HTML foundations, your CSS will be fragile.) From page to page, your HTML should seem familiar in it’s use of elements and identifiers.

Take this snippet of common HTML as an example…

<div id="container">
<div id="header">
<h1 id="site_name">Acme Inc</h1>

Welcome to Acme Inc.  Explosives 'R Us.
<div id="navigation">
	<li class="active">
				<a href="/">Home</a></li>
				<a href="/about">About Acme</a></li>
				<a href="/contact">Contact Us</a></li>

Now, your CSS can reflect this structure. If you’re familiar with your own HTML (as you should be!) then laying out your CSS in a fashion similar to your document tree will go a long way in making your CSS more readable.

Start with empty rules for each element in your common HTML:

/* =============================== *\
|  Document Tree                    |
\* =============================== */
body {}
	div#container {}
		div#header {}
			h1#site_name {}
			div#header p {}
		div#navigation {}
			div#navigation ul {}
				div#navigation ul li {}
					div#navigation ul a {}
				/* Active navigation item */
				div#navigation ul {}
					div#navigation ul a {}


Indenting as Ancestry

By using tabs, we can indicate which elements are subordinate to their parents. A tab for each generation. This does shift your properties into the right-hand side though – Some folks aren’t happy with horizontal scrolling in their IDE of choice, but once you get over that you can quickly navigate your CSS. It’s very important at this stage to disable Word-Wrapping, else it won’t make visual sense.


Describing identifiers

You’ll notice I prefix each one of my identifiers (e.g. #navigation) with its associated element. In this case, a div prefix. One typically doesn’t assign an identifier to any other type of element, so why not improve the readability of your code by describing what element it is.
div#navigation says a lot more than just #navigation. Some of the kilobyte purists out there might disagree, but if you had to inherit this code, which would you prefer?


Prioritised Properties

A lot of folks write out a property for each line, like so…

div#navigation ul a {
background:transparent url(img/bg_nav_item.gif) top right no-repeat;

I find that difficult to separate rules from properties, even with syntax highlighting on.

I prefer to layout the rules horizontally so that it doesn’t break the document tree we created earlier.

div#navigation ul a {display:block; float:left; background:transparent url(img/bg_nav_item.gif) top right no-repeat; text-decoration:none; color:#000;}

This requires a prioritisation exercise though.

Once you start assigning properties to each rule, it’s important to order these properties based on how ‘drastic’ the rule is.

  1. Block level changes and layout properties should come first.
  2. Follow that up with background properties
  3. Then tail it off with text and font decorations and colour.


Modular CSS

I then create a section in my CSS for reusable modules within the site.

I typically create a module for:

  • Tables
  • Forms
  • General Content

An example:

/* =============================== *\
|  Modules                          |
\* =============================== */
div.form {}
	div.form form {}
		div.form fieldset {}
			div.form div.form-row {}
				div.form input.text {}
div.table {}
	div.table table {}
				div.table thead th {}
				div.table tbody th {}
				div.table tbody td {}
div.general {}
	div.general p {}
	div.general ul {}
		div.general ul li {}


Live time

Hopefully your software project doesn’t end before it begins. But when it’s time to go live, you’ll need to optimise your CSS, especially in its use of spaces and tabs. Strip out all the tabs and remove unnecessary spaces. Of course, you could leave it as is if you have to maintain it later.

Thank goodness for caching!



I hope this article helped you in creating easy-to-read CSS. CSS doesn’t have to be dirty and difficult to maintain. Keep it clean and it’ll look after your site’s styling needs in an efficient and intelligent manner.