Skip navigation

Category Archives: Development

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.

Brad Abrams was recently in Cape Town to talk at Mix. Ernst pointed out that the crowd managed to steal Brad for a night to give us a talk on the upcoming MVC Framework for

I know very little about and I’m quite interested in MVC frameworks. (since most of my work involves the V in MVC). Have Microsoft finally come to the MVC party then? I put my name down for the Wednesday night talk to investigate.

In the past, as an outsider, I always looked at Microsoft-related web application frameworks with some manner of distaste. The markup it produced was horrible. It required licensing fees. And the caliber of the average developer was nothing short of mediocre. My ignorant, judgemental foundations. I decided to cast my judgements aside and see how the other half works.

Brad’s talk gave a brief intro of MVC. Familiar territory. A Controller prepares the Model for a View. Views are presentation only, etc. In contrast, is what’s traditionally known as a Model 1 Framework. Business logic can be and is used within the View. To get the most out of, some developers have created their own MVC frameworks using with much success. This is the first time Microsoft is adopting MVC in an official capacity. About time.

Brad described how the team in Seattle was working through the transition from View-Centric architecture to the more separated MVC approach. They’ve broken many things along the way, but they’re forging forward.

The IDE is quite a beast. Helper functions pop out of every period. I imagine that a competent developer can generate code at lightning speed within Visual Studio. Quite the stark contrast between say using Emacs.
Being familiar with Altova‘s excellent XMLSpy, I almost felt a kinship with Visual Studio’s interface.

The IDE has it’s typical Projects folder, with subfolders for Models, Views and Controllers, and interestingly enough a whole section dedicated to Unit Testing components.

Brad flipped through some Unit tests, created a Controller Function and generated a corresponding View. No more horrible markup, the markup is as you want it. Semantic HTML output baby! Then I was stumped by the template syntax. Apparently they’re working on the presentation logic, but it was like stepping back in time. Run-time Percent tags wrecking the View. Brad explained that they’ve had to resort to old template syntax until the View matures and they start using Tag Libraries or such.
Then it was just like they did in those cooking shows: The buzzer went and the chicken popped out the oven, freshly roasted. A full blown web app chicken. The buzzer in my brain went off too, I realised at that point that I really need to do more development – make my own apps, to tinker and understand.

On the whole, the dot net MVC Framework has legs. The majority of the audience was keen to adopt MVC, with the provisor that the framework mature a little. I think a lot of developers present have a vested interest in the old ways, since so much work has been done there already, it’s also quite a mindshift from just working in the templates. Still, MVC could potentially be used on a new project.

I came out of the talk with a new found respect for and the rather-formal Microsoft geeks. I think the adoption of MVC as a Web App Framework is a positive step forward by Microsoft. (I’m too happy with Python and Genshi at this point to switch over though.) The Views in MVC still have a long way to go before it can be considered a worthy contender in the Web Application Framework games though.

Update: Brad Abrams has blogged about his stay in South Africa, plus put up the slides and demo from his talk about MVC.  Good one Brad!