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.

15 thoughts on “How I write my CSS, and why

  1. jem

    My approach is fairly similar to this.

    I don’t capitalize tags, because tags aren’t capitalized in the HTML, so I guess that wouldn’t make sense to me.

    I do the single-line thing, but i keep it all in alphabetical order. I use to break it across lines, and yes its more readable but the CSS files just get enormous when you do this (and most projects I work on no server-side CSS compressing/caching is in place).

    I have yet to work on a project where I’ve broken CSS into multiple files, its all got to be loaded anyways, breaking into more files just means more requests to the server which I think is bad. I could see this being good if you’re doing a large site with lots of UI-like styles to break them into pieces.

    I also use comment blocks in the CSS to denote the start of styles for a particular “section” and so forth.

  2. Thomas Aylott

    I often have to work with teams of devs I’ve never met before and will never see again. Multiple internal styles.

    I highly recommend CSSEdit.app on the Mac. Very very nice for quickly getting stuff done. Especially new projects.

    Here are my rules…

    * Small focused separate css files. Compiled into a single compressed file using a build script for production mode only.

    * Never Indent anything but properties.

    * Never commit single-line rules. (as the maintainer of the CSS.tmbundle I’ve added a number of tools to quickly reformat your selection, might be in experimental on my github only)

    * Always reformat all sheets as a separate commit before beginning anything new on an existing project. (for some reason clients go nuts for this simple reformatting ;)

    * Sort properties in logical groups when hand coding. TRBL sorting. When using CSSEdit I just let it do what it does.

    * Prefer separate IE css, but also mix only very stable IE hacks into my main CSS file. I’ve tried keeping them separate but it becomes a maintenance issue.

    * Use CSSEdit Groups to keep things separate when separate files aren’t possible.

  3. Thomas Aylott

    Above all I believe it’s important to have a style and stick to it.

    My only die-hard rule for css is separate files for each “component”. If you can get people to agree with that one then the rest is a non-issue.

  4. Thomas Aylott

    Also, I believe that it’s important to stick with the style of any project you join. If I joined one of your projects I would use your style to the best of my ability. But if you joined my project I’d expect you to code to the project standards. And I’m sure you would.

  5. Fabio M. Costa

    yeah cool, i liked your points but my style is different, totally. I liked the uppercased tags, but won’t use it hehe.

    And i use my ie css hacks (i try to make them smallest as possible) on the same file because its easier to maintain. I mean if you have to change something after the site has been deployed you’ll change the original css but for sure will forget the ie hack file.

    But nowadays im ust using hacks for png transparency (most of the times), which i keep on a different file.

  6. kas187

    My approach is pretty similar to Darrens’ and i guess working with him does rub off some tips and tricks. One thing i always do is to split my stylesheets (modularising) so layout, typography, main etc etc. It’s much easier to maintain a bunch of files and has benefits of long-term maintenance.

    What I also do is to include a snippet of comments at the beginning of each stylesheet which gives an overview of what the stylesheet is about and a brief table of contents with keyword searchability to different sections.

    What i also do is to keep a naming convention consistent throughout the html, css and javascript so that i know what belongs to what.

    Oh and thats 2,000 liner, yeah I remember that so don’t bring back memories.

    With regards to IE hacks. I never include any in the main stylesheet. All IE hacks, filters and work arounds are in a separate stylesheet which again is a for long term maintenance.

    What I have also started to do on projects where IE6 is not needing support is to follow a Object orientated approach to CSS, so extending any components with addition of class and necessary styles / js (Moo FTW!). Nicole sullivan has some great tips on how to do just that so google is your friend.

    Thats it from me. Great article and nice to see how other developers approach this.

  7. akaIDIOT

    Although I might not agree on all your styling rules (harhar), the main thing here is to be consistent and sensible about these things. Too often these things become a mess when more then one person is to edit the files.

    What I’m missing in you article is a naming convention for class names. I usually use hyphened class names like .some-class as everything else in CSS is lowercase. I imagine you and other people would have different approaches to this :)

  8. basher

    Small, modular CSS files – definitely.

    IE styles in separate sheets – again, a must.

    I’m not a fan of single-line declarations, but we use them at work, so it’s a case of fitting in with the team.

    I tend to group my properties logically – e.g. font-related stuff, box-model stuff.

    With Firebug I don’t see the need for alphabetic ordering… even though I do suffer from OCD!

    Nice article… looking forward to reading more.

  9. Morgan

    nice article, though I have to agree when I did/do get my hands dirty with CSS I think alphabetic ordering is above and beyond.. do you have days for your socks? :p

    That said I’m more of a tinkerer than a full blown CSS guru, so some very interesting reading in the above..

  10. Espen 'Rexxars' Hovlandsdal

    The uppercased tag names sounds weird to me, I guess I’m used to XHTML by now – seeing HTML with uppercased tags gross me out, so I avoid that in CSS aswell.

    I like the readability of multi-line style declarations, but for my latest project I went with single-line. I find it a bit easier to see the different “sections” of the site this way. Yet to decide which method I like best though.

    If I was given enough time I might use alphabetic ordering, but I don’t :p

Comments are closed.