Reasons to avoid single-line CSS

Coding styles are very personal. I try not let myself get caught up in arguments about them, but after reading Simon Collison’s tweet yesterday, I was intrigued about the article to which he was referring (I’m a great admirer of Simon’s work). Having read the article, I was surprised at the author’s justification for his choice of single-line CSS.

In the article, John Nunemaker says he prefers writing selectors and their attributes on the same line because it:

  • Makes selectors and their attributes quicker to scan
  • Reduces the size of the CSS file
  • Saves him time when creating and editing CSS

I’ve created both single-line and multi-line stylesheets myself, and I’ve experienced more effective methods of speeding up the creation of a stylesheet whilst maintaining a friendlier method of formatting, and better ways to reduce it’s file size too — without having to resort to using single lines. The context I’m providing for my methods is that of a team environment, where multiple designers and developers will have to maintain the CSS you create, and where the CSS will be version-controlled. Even if you create and maintain CSS entirely on your own, I still believe using this kind of environment as a benchmark is hugely beneficial.

Stop scanning and get alphabetical

Visually “scanning” large CSS files wastes time and creates fatigue. Why not just search for your selector by keyword? Alternatively, simply inspect the element using Firebug, read the selector’s line number from the ‘Style’ panel and use the ‘Go to line’ feature of your text editor (Cmd+L in TextMate). Provided you are Commend+Tab’bing (or Control+Tab’bing if you’re on Windows) between apps, all of this take seconds and saves you scrolling up and down a honking great CSS file.

If you are a “scanner”, a great deal of scanning fatigue can be avoided simply by formatting the main sections of your CSS in a structured manner and by listing your selector attributes in alphabetical order. “That’ll take forever!” I hear you say. Wrong. When my developer colleagues Matt and John (the best two front-enders I’ve known) got me listing my attributes alphabetically, I was surprised at how little extra effort and time it actually took. Believe me, any extra time or effort it does require when you begin coding this way is paid back in dividends when it comes to scanning your file. Even before you begin scanning selector attributes, you know roughly that border-radius will be near the top, and z-index will be right at the bottom. Other designers and developers maintaining the CSS can immediately benefit from the formatting. It makes so much sense.

Single-line isn't tidier

Browser vendors are implementing CSS3 modules into their rendering engines at different times and in different ways. This forces us to use vendor prefixes such as -moz- (Gecko: Mozilla, Firefox), -webkit- (Webkit: Safari, Chrome) and -o- (Opera) as part of our selectors. Imagine for a moment you want to put rounded corners on an element, and you want each corner to have a different radius. It would look something like this:

div {
  border-bottom-left-radius: 5px;
  border-bottom-right-radius: 6px;
  border-top-left-radius: 3px;
  border-top-right-radius: 4px;
}

That’s bad enough, but it’s infinitely more scannable than it’s single-line variant:

div { border-bottom-left-radius: 5px; border-bottom-right-radius: 6px; border-top-left-radius: 3px; border-top-right-radius: 4px; }

Although this is an admittedly obtuse example, bear in mind that this is only for the border-radius styling of the element. It’s quite feasible to think that there could be another five or six attributes added onto this selector in order to achieve the desired styling. “But I don’t have wrapping turned on anyway”, you say. You’re still going to have to do a lot of back-and-forth along that old x-axis of yours when scanning for attributes.

Consider the majority

The vast majority of front-end designers and developers I’ve worked with prefer the multi-line approach. It’s more familiar to them, and as a result find it easier to work with. In a production environment where there are very large CSS files in need of maintenance by different people of varying skill levels, it makes sense to use methods that the majority is comfortable with. Creating code that multiple designers and developers are at odds with in a company only results in friction and causes frustration, slowing the pace and creating resentment.

Why make debugging harder?

If you use version control (and let’s be honest, you should), you’ll no doubt have had to compare two conflicting files in your time using some sort of diff utility. Sorting this kind of stuff out is never fun, but we can at least take steps to make it quicker and easier. In his article ‘Be kind to your friends: hit return’, Jason Cale mentions:

If you have declarations that are all on one line, you cannot diff effectively as the changes are not clearly marked.

If you find it hard scanning through a single-line formatted CSS file, try scanning two at the same time. It saps time and is a frustrating exercise. There are more important things to be using your time for.

But what about file size?

If the size of your CSS file is very important, try using a tool like YUI Compressor or Minify to compress your files for serving up on a live site, keeping your own multi-line formatted copy nice and tidy.

I don’t want to come off as if I’m preaching here; if single-line formatting works for you, cool. But if the CSS you’re authoring is to be implemented or maintained by multiple people, try to think about how you can effectively reduce their workload.