How I write my CSS, and why

I work with a team of awesome Front End Developers, who’s main job it is to take the designs and code it into accessible HTML and CSS. There are currently 4 of us, and a couple more have been and gone.

We all kind of agree on how we structure our HTML – in a way that is semantically sound, and accessible – but one thing I’ve noticed is how different my views on how I structure my CSS are compared to my colleagues. I thought I’d explain myself, and hope to gain some insight into what others think about my style, given my reasons for choosing it.

I always capitalise my tags

I can’t actually remember when I started doing this – I guess it was right from the start – but I always capitalise any HTML element in my CSS. For instance:

DIV LI.selected A

I do this because I really believe it’s more readable. IDs are very recognisable because of the # sign – classes, when quickly scanning CSS, are less easy to spot, because the period isn’t the most noticeable of characters. By capitalising my tag names, I can easily differentiate between IDs, tags, and classes.

I always order my properties alphabetically

When I mention this I normally get accused of having horrific OCD, which is probably quite true; a lot of people prefer to group properties by type; as in, top, left, right or border, padding, margin.

My argument for this is that if you order alphabetically you eliminate two possible problems; first of all, duplicates (however unlikely); second of all, gotchas like specifying a font rule after a line height. Compound properties (like font, background etc) implicitly include other rules in them. The main one – font declaration implicitly includes line-height.

line-height: 16px;
font: 1.2em Helvetica, Arial, sans-serif;

In the above example, the line-height declaration means nothing. It is overriden by the font declaration. Ordering alphabetically eliminates this as a potential problem.

It also means when I’m looking quickly for something I know whether to look at the beginning or end of a set of properties.

Single-line declarations FTL

This is something that me and some of my colleagues can agree to disagree on. I HATE single line declarations. I find them so unreadable. One of my first experiences with single-line CSS was this horror show of a 2,000 line stylesheet – each one on a single line. First off – no way should you have 2,000 lines of CSS in one file – but the single line format killed me.

5 or so years ago this could have been considered best practice, given the prevalence of dial-up.  Now with broadband, whilst abusing a user’s connection is not encouraged, it’s not so much of a problem. The extra line breaks aren’t going to add up to much in terms of file size – so do yourself a favour and put your properties on separate lines.

It’s worth noting that whenever you see a ‘CSS formatter’ (like this one) if you format it as ‘readable’ then it takes the multi-line approach. Single-line declarations are rubbish.

Also the argument that it’s harder to find a rule if you don’t put them all on one line is, in my eyes, invalid – Firebug tells me exactly what line it’s on.

I put IE specific hacks in separate stylesheets

Again, I find it extremely annoying when people put IE hacks in the stylesheets. They should be separate. I have a whole blog post in the works dedicated to IE hacks so I won’t go into any details here :)

I indent my CSS to show when a declaration is a child of another

UL {
  list-style: none;
  margin: 0;
  padding: 0;
}
    UL LI  {
      color: #CCC;
    }

By doing this I can clearly see what rules belong to what definition – again I chalk this down as personal preference but I find indenting like this to be much more readable.

Use the server to compile your CSS – then break it up into chunks

If you are working on a site that has so much CSS that it’s a performance problem to have lots of small, manageable CSS files, you need to invest the time on building something that collates and compresses them for you. This is NEVER an excuse to not break your CSS up into small manageable chunks, but rather a failure to use the tools you have to make something manageable and maintainable.

I’ll definitely be doing some posts in the future about this subject with simple C# and PHP examples.

That’s how I do it – what about you?

That’s how and why I structure my CSS like I do. I find that having a structure for CSS is something that a lot of people don’t do – it’s often an afterthought for a lot of Front End developers I know. I’d love to know what you think of my eccentric CSS-based behaviour and what works well for you.

About this entry

You’re currently reading “How I write my CSS, and why,” an entry on fakedarren

Published:
10.30.09 / 6pm
Category:
CSS
Tags: