Single-Line vs Multi-Line CSS, plus TextMate tips

Written by Ben on 23.03.2010

Now that the stormy debate around whether or not designers should be able to code what they produce has died down, the new debate du jour is here! Or rather, it’s back again. This one has been around before, and it’s about whether laying out your CSS code on single lines (one selector per line), or multiple lines is better.

In the red corner; single-line CSS code formatting:

1 2	header h1 { float: left; width: 155px; height: 50px; } header h1 a { display: block; opacity: 0.8; border-bottom-width: 0; }

In the blue corner; multiple-line CSS code formatting:

1
2
3
4
5
6
7
8
9
10
11

header h1 {
float: left;
width: 155px;
height: 50px;
}

header h1 a {
display: block;
opacity: 0.8;
border-bottom-width: 0;
}

The principal argument for coding on single lines is that you end up with a file that has all your selectors stacked up on top of each other, allowing for easier eye scanning when hunting for a specific selector.

The most common argument against is that when you’re working in a source controlled environment (which of course we all are because we’d be idiots not to, right?) and a change is made to the CSS, there’s no way with the single-line approach to quickly see which property was changed and how. Here’s a modification to some multi-line CSS code:

And here’s how the same modification would look if this was a single line statement:

It’s obvious from the multiple-line example that the background-color property has been changed from transparent to “#fff”, but in the single-line example the actual change isn’t highlighted because differentiators only work on a per-line basis, so it just reports that the whole line has changed. It will be up to you to work out which property was modified. Now talk to me about “easier to scan”.

For the most part, and complexities during source control diffs aside, this is simply a case of personal preference. Opinion is divided right down the middle as to which is better, with no fence sitters because really you just have to pick your preferred option (as a team if there’s more than one CSS coder involved on a project) and stick to it for consistency. Saying that it’s best practise to use one technique or the other isn’t really helpful — just figure out what works for your situation and environment and stick with that.

My preference is for multiple-line CSS, because that’s how I’ve always done it, I use source control on every single project (even solo projects), and my process for designing and front-end coding involves inspecting elements in Firebug, testing modifications to markup and style, then using Find ⌘F to jump immediately to the relevant selector I want to change. This involves no visual scanning for selectors in my code editor, and once you have the required keystrokes wired into your brain I guarantee that this is far quicker than scrolling and scanning for selectors, even with single-line CSS formatting.

But enough of this petty bickering debate! Because I’m lucky enough to be a TextMate user, this is all completely academic. Here are two quick TextMate tips for multiple-line CSS coding to help with finding selectors, if you want the best of both worlds.

When editing a CSS file, you’ll have a “Symbol Navigator” in right side of the status bar, which displays the currently focused selector based on cursor position. If you click the Symbol Navigator, a menu appears which displays all your selectors in a very easily scannable list. Simply click on one to jump straight to it.

You can also use the shortcut ⌘⇧T to pull up a “Go To Symbol” dialog, where you can type part of your selector and it will suggest matches. Use the arrow keys to move up and down the matches, and the Enter key to jump to that selector in your file. Hat tip to Doug Neiner for that one.

TextMate screenshot showing Symbol Navigation

There’s also a quick way to jump between what is effectively a selector only view and your standard multiple-line format, by making use of Code Folding. While editing normally and laying out code using the multiple-line technique, your code will look something like this:

But if you use Code Folding to collapse your code on all levels (and with vanilla CSS there will only be one level anyway) using the shortcut ⌘⌥0 then you’ll reduce your display of your code to this:

This view will help you scan selectors quickly without the attributes getting in the way. When you’ve found the selector you want, pushing ⌘⌥0 again will return you to the unfolded view.

Notice by the line numbers that I’m not afraid of large CSS files, and why should anyone care about that? It’s 2010 and we have smarter text editors these days than the days where a 2000 line file was a big deal because of all the scrolling we had to do. CSS should be minified as part of your deployment process to your production environment anyway, so this is a non-issue for your end users who are served the file.

So, go forth and code in whatever style you prefer. Hopefully this shows you that if you have the appropriate tools for the job, smaller details like code formatting start to matter a lot less which allows us to spend our energies on coding more and better things, instead of arguing about how we code.

Update: Sean Gaffney commented to tell us about another TextMate shortcut: ^⌥Q which properly converts multiple-line CSS to single-line. Thanks, Sean!

Update 2: Another killer TextMate tip, this one from Doug Neiner – Hitting ⌘⇧T while editing a CSS file will bring up a “Go To Symbol” dialog with a list of all your selectors, which is much cleaner than my method for searching using Find. This “easier to scan selectors” argument for single-line CSS is really shot to pieces if you’re a TM user now. Thanks Doug!

Ben Bodien is Principal & Co-Founder at Neutron Creations, where he oversees product design and front-end development. For a somewhat balanced mixture of ranting and raving, follow him on Twitter: @bbodien.

46 Responses

Stefan Nitzsche

March 23rd 2010 @ 6:02 pm #

In Germany we discussed this problem a lot. We came to the solution that it always depends on the preferences of the developers involved. I think, there’s no “right” solution.

And: it’s about collaboration: everyone in your team has to understand how you write your code, and why you do it this way.

Fo the lone warrior, every solution is possible as long as the result is (more or less) valid, good code.
Sean Gaffney

March 23rd 2010 @ 6:42 pm #

In TextMate, ^⌥Q will also minify your CSS for you into single line code. I like to do this on certain blocks of CSS that I know I won’t be editing much while I hammer away at the rest of my code, making scrolling less of any issue.
Geert De Deckere

March 23rd 2010 @ 6:44 pm #

I recently tried to switch back to multi-line CSS. I think I’ll try to stick with it. TextMate helps a lot.

Next topic: in which order do you place your CSS properties? Alphabetically? And to include a space after the colon or not to?
Ben

March 23rd 2010 @ 8:25 pm #

@Stefan absolutely, it’s crucial that everyone on a team agrees and sticks to a coding standard when it comes to this kind of thing. Discuss the factors that are important for your specific context and make the decision according to those.

@Sean great to have you drop by – really enjoyed the CSS3 stuff yesterday! And thanks so much for that shortcut. File that under stuff about TextMate I’ll wonder how I lived without.

@Geert I tried alphabetising properties, but on a full-size web app project that soon becomes laborious. Instead I try and group properties by loose categories: “position”, “typography”, “aesthetics”, etc.
Yaili

March 24th 2010 @ 12:40 pm #

I’m sorry, but I just can’t get my head around multi-line CSS. I don’t think the diff argument should be a decisive factor either — software should be capable of reformatting your CSS as you please. Also, you should be competent enough to create a CSS that considers specificity, so reformatting won’t break anything—to a degree, of course—, right? :)

I must confess, though, that the tips you’ve mentioned for TextMate look rather sweet, specially the scannable list of selectors, which is basically what you get if you’re using single-line CSS.
Aaron Witherow

March 24th 2010 @ 12:59 pm #

Single line CSS aids scanning for selectors but it makes it hard to see the property values. Multi line is much better as I break up the style sheet based on what it is, navigation, content etc and have comments for page specific. Even a prefix for a page or section e.g. #hm-search-bar. All you have to do is search and you are editing straight away.

Single line means you end up scanning horizontally to find specific properties. Nightmare! I also mix single line and multiline, if the selector only has two or less rules it goes on a single line if more multi line. Same for combining selectors multi line too e.g.

#content,
#header,
#footer{
border:1px solid red;
}

I also tried putting properties alphabetical but too much work when you are trying to knock out some code. As mentioned there is no right solution but a system is more important.
Tom Kenny

March 26th 2010 @ 12:14 pm #

What’s more important to me is well commented CSS. I’m a single line fan but don’t mind having to work with multi-line code especially if it’s well commented.
uberVU - social comments

March 26th 2010 @ 12:18 pm #

Social comments and analytics for this post…

This post was mentioned on Twitter by andymm: Single-Line vs Multi-Line CSS, plus TextMate tips http://ntrn.cc/aVddmp (via @NeutronUK)…
Hian Battiston

March 26th 2010 @ 12:22 pm #

I prefer to use multi-line describing every piece of it, because in this way it’s easier to fix the problems when its show up, also it’s more visually correct.
eGandalf

March 26th 2010 @ 12:35 pm #

Honestly, for selectors with more than just a few properties, I find the multiline approach much easier to scan. Hian also makes a very good point about being able to comment on the properties using the multiline approach – something that would only clutter the single line method.
Alfred Reinold Baudisch

March 26th 2010 @ 9:37 pm #

I’ve always used multi line CSS for one simple and quick reason: code readability and manageability.
Will

March 26th 2010 @ 9:54 pm #

multiline plus search, there is no substitute. :)

textmate has a few ways to search. cmd-f is the obvious one but there’s also ⌃S or ⌃⇧S. This one incrementally searches forward/backward as you type.

use a pattern to name your sections like /**Typography**/ and you can always search for ‘/**T’ to jump there. Bookmarks work great too since you can just cycle through them with a single key.

I’m also a big fan of alphabetized selectors. took me a couple of months to really settle in but now I can’t go back.
Mike

March 26th 2010 @ 10:51 pm #

Single line + properties order + indent to reflect html structure. I will never go back to multiline, that’s equally lame as css editors.
ertan

March 28th 2010 @ 4:42 pm #

I’m using single line and multiple line. single line for small basic jobs, multiple line is complex projects.
Tyce

March 28th 2010 @ 4:43 pm #

Single line is incredibly frustrating to edit, and very hard to differentiate between selectors.

I’ll always code multi-line, it’s just how I’ve learned and can work fast, efficiently and effectively.

I understand the need or want to minimize stylesheets, but can’t justify compressing all those lines of code for the sake of a kb or two.
steve firth

March 28th 2010 @ 4:46 pm #

You hit a sad nail on the head when you said “because that’s how I’ve always done it”

Just use some common sense, multi-line is more legible but takes up so much screen space you can’t see as much at once, but if there are so many values you can’t easily scan it then single line is making work for you …

I use single and multi-line because I’m capable of making sensible judgements.

If you’re using single or multi then give it some order:

size > position > padding/margin > background/colors > text formatting

Truth of the matter is single/multi makes no dif when most people don’t even reset their CSS and after reading this they’ll just being doing something else they copied with no real appreciation as to why.
Andreas Papula

March 28th 2010 @ 4:49 pm #

Multi-Line, because it is better to comment and read.
Nguyen Ngo

March 28th 2010 @ 4:54 pm #

I’ve been with both multi-line CSS (for my first time) & single-line CSS, each have its own advantage & disadvantage, depends on the developers & team-members. You cannot tell which one is better; however, I’m now mostly use single-line CSS for file-size reduce, easy (default) reading code, and because I know my own CSS coding style.

#selection, .selection{ position comes first, dimension comes later, font/list/… styles, color & others}
Alexander Moya

March 28th 2010 @ 4:58 pm #

When I started designing websites, I used multi-line CSS, however in the most recent months I’ve developed a new technique, I write in multi-line CSS and when the time comes to publics the website (generally using WordPress) I create a php stylesheet that I can gzip, also the new php file has the entire css on one line. Cleancss.com helps a lot in this.

The advantages are many, I keep a clean, commented and highly readable style.css file, for developers and a quick to load, efficient and compression friendly style.css.php for the browsers, the don’t really need a developer friendly css ;)

The main disadvantage is that you need to modify style.css.php every time you change something in style.css, witch really shouldn’t be that much of a problem.
marcel

March 28th 2010 @ 5:07 pm #

Since I’ve been using SASS (http://sass-lang.com) this is no longer a problem.

The switch from single to multiline css is just one lever in the configuration :)
Tyler

March 28th 2010 @ 6:35 pm #

I tend to use the multi-line approach for any selectors that have more than 2 or 3 styles. So, I like the tidyness single line has to offer but I guess overall I prefer multi-line because it’s easier to read.
Single-Line vs Multi-Line CSS, plus TextMate tips « Neutron Creations « Netcrema – creme de la social news via digg + delicious + stumpleupon + reddit

March 28th 2010 @ 7:40 pm #

[...] Single-Line vs Multi-Line CSS, plus TextMate tips « Neutron Creationsneutroncreations.com [...]
Sean Curtis

March 29th 2010 @ 12:16 am #

Has anyone come across any TextMate bundles that allow you to toggle a CSS file between single and multiline?

Personally I prefer single line css, however I hate viewing diffs of it so I end up using multiline when working with svn.
Marcel

March 29th 2010 @ 1:35 am #

Nice article, but don’t you see your (not very contrasty) text becomes unreadable on the left side in front of that color wheel? Just resize your browser window to a width of 1024px and you’ll see what I mean (and I usually use that width, because other sites become to wide when using 1280px).

No insult intended, but really, this is annoying. (Moreover, that wheel creates a ‘jump’ effect when scrolling in Firefox.)
Ben

March 29th 2010 @ 12:20 pm #

@Marcel Thanks for picking up on that, it’s something I’ve been aware of for too long without fixing, sorry! I’ll get the problem sorted this week and stop putting it off.
[vladi]

March 29th 2010 @ 12:43 pm #

I personally prefer the multi-line css. It is easier for me to see what each selector “does”. Also, I have my own style of ordering selectors, which organizes them in a logical (for me) style:

1. *
2. standard HTML tags (h1, p, a, …)
3. div-specific (#navigation, #navigation a, …), grouped and ordered logically
4. common classes (.cb {clear: both}, .ac {align: center}, …), usually single-line, since they only have a single attribute

After I have spent numerous hours of editing that stylesheet, I know exactly where everything is. It also persists between projects, since I tend to use similar names, structures, etc. so scanning is not really a problem, even after a year or more has passed.
Doug Neiner

March 29th 2010 @ 1:52 pm #

Ben,

Awesome write up. I too use TextMate + Multi-Line format, and I couldn’t think of ever switching. I occasionally use single line when working with sprites, so I can select and edit columns across multiple roles at a time but thats about it.

You missed a big timesaver in Textmate though… I know the symbol navigator menu is nice, but whats even *better* (aka, I use it so its “better”, right? ;) is the “Go to Symbol” window.

If you type ⌘⇧T in a CSS document, you can then type a few letters of the selector you want, and it filters the list. You can then hit up/down then return to jump to the exact rule. Its so fast, and leaves your hand on your keyboard.

If you have a comment with more than one asterisk, it will show up as a section header: /** Section Header */

Awesome article… I will be sure to pass it on!
Ben

March 29th 2010 @ 2:05 pm #

@Doug Fantastic tip, thank you so much! I’ll update the post with that one too. I love hearing from other TM users and I always pick up new shortcuts and tips – it reminds me that I really only scratch the surface of the app in terms of what it can do.
Marcel

March 29th 2010 @ 2:10 pm #

@Ben: Great that you actually recognize these drawbacks! You’re one of the few designers I know that really do something with criticism on their own web sites (of course only meant to improve them).

One more thing though: it’s not easy to recognize the submit button as it doesn’t look like one, despite the large text (the same is true for the search box).
Sean Gaffney

March 29th 2010 @ 2:18 pm #

@Ben – Thanks for the kind words about our presentation. :)

@Sean Curtis – Within the default CSS bundle, there is “Format CSS” and “Format CSS Compressed”. The former formats to multi-line, the latter to single line, which allows you to switch between the two methods easily (they both have keyboard shortcuts as well, the latter of which I mentioned previously).

@Doug – What a brilliant little shortcut, thanks for sharing!

Alexander pretty much hit the nail on the head. Program in whatever you want, whichever allows you to work efficiently. Then, when you push your code to production, make sure it’s minified and Gzipped, etc. CSS “Frameworks” like SASS allow you to do this with relative ease.
Greg

March 30th 2010 @ 4:59 am #

I use a hybrid approach when I don’t think the project will call for minification. Easy scanning/modifications, even moreso during the design phase than the maintenance phase… after all, search is easy (esp. with shortcuts) but scrolling up and down to remind yourself of what’s already been built is easier when compact.

Just to stir another sh**pot, though: There’s a current trend for minification obsession that I don’t understand. Some people are missing the forest for the trees. Unless your site has a script that will do the minification automatically in the back end, why bother for smaller sites? “Always minify” is a questionable best-practices statement. If your CSS is only 2KB, you’re not really going to care about the savings. Time spent optimizing images will reclaim far more than that, a better investment than re-minifying after each change.
2010-03-30 유용한 링크 | We are connected

March 30th 2010 @ 6:07 am #

[...] Single-Line vs Multi-Line CSS, plus TextMate tips [...]
Shahriat Hossain

March 30th 2010 @ 6:45 am #

Nice stuff here though I like multiline css for lots of properties and singleline for short list properties.
Nicola Pressi

March 30th 2010 @ 8:38 am #

I love TextMate… and now I love ctrl+alt+Q!
Fantastic!
Ben

March 30th 2010 @ 10:39 am #

@Greg You’re quite correct that savings will be minimal when dealing with very simple sites with small CSS files, and that your efforts in optimisation might be better focused elsewhere. One thing that is still very helpful is to flatten your CSS (and JS) files into a single file, to reduce the number of requests being made to the server which is where you’ll have more significant latency in establishing connections if your files are small.

For example, we have plugins in our deploy script that even on simple sites will combine our reset CSS and our screen CSS into one file. We’re still talking tiny savings but it all adds up.
Marcel

March 30th 2010 @ 2:15 pm #

@Ben: You’re right about reducing the number of requests being made when all your CSS (and JS) is in one single file. Only notice that the iPhone will not cache files bigger than 15 KB. See http://www.niallkennedy.com/blog/2008/02/iphone-cache-performance.html

Also notice that dynamic scripts combining several CSS/JS files usually don’t set any caching parameters in HTTP headers by default, causing an HTTP request every time the single CSS/JS file is linked to (at least when using PHP).
CSS-Code organisieren | Peruns Weblog

March 30th 2010 @ 10:34 pm #

[...] zwei englischsprachigen Artikel Single-Line vs Multi-Line CSS und Single Line CSS haben mich dazu gebracht ein paar Worte dazu zu schreiben wie ich meinen [...]
CSS Tips I Wish I Knew When I First Started | MyInkBlog

April 20th 2010 @ 3:39 am #

[...] to alphabetize or prioritize your properties, still others wrestle over whether to put css on one line or multiple lines. For the record, I use hyphens, alphabetize, and single line, and that’s definitely the right [...]
CSS Tips I Wish I Knew When I First Started - Programming Blog

April 20th 2010 @ 9:52 am #

[...] to alphabetize or prioritize your properties, still others wrestle over whether to put css on one line or multiple lines. For the record, I use hyphens, alphabetize, and single line, and that’s definitely the right [...]
Michael

May 23rd 2010 @ 5:43 am #

I’ve just started using a combination so I can group selectors. Here’s what I have right now:

.someclass { styling (color, border, background…)
font (font stuff)
layout (padding, position…)
css3 (one line per group (border radius)) }

So far I like it. For me it’s a good mix of compact and readable.
CSS Tips I Wish I Knew When I First Started | othercreativedotcom

June 5th 2010 @ 6:35 am #

[...] to alphabetize or prioritize your properties, still others wrestle over whether to put css on one line or multiple lines. For the record, I use hyphens, alphabetize, and single line, and that’s definitely the right way [...]
James King

June 8th 2010 @ 11:36 am #

I spent years using the multi-line approach, until I joined a front-end team on a large website, where they used the single line method.

I found it difficult to adapt at first but when you are dealing with large CSS files, the single line approach allows you to easily scan your selectors. Yes it can make it difficult to scan properties if a selector has more than 7-8 properties, but if you have firebug open constantly, and inspect any item, you can easily see all the properties.

Since then I have I haven’t looked back.
Dwi Texas

July 5th 2010 @ 1:13 pm #

Just to stir another sh**pot, though: There’s a current trend for minification obsession that I don’t understand. Some people are missing the forest for the trees. Unless your site has a script that will do the minification automatically in the back end, why bother for smaller sites? “Always minify” is a questionable best-practices statement. If your CSS is only 2KB, you’re not really going to care about the savings. Time spent optimizing images will reclaim far more than that, a better investment than re-minifying after each change.
+1
Kaelig

July 23rd 2010 @ 11:28 am #

Folding all levels with one shortcut is very useful when you indent css.
Christian

August 27th 2010 @ 5:32 pm #

I know I’m in the minority here but one thing that makes it much easier to read selectors is to put the HTML elements in uppercase, and to have class and id names in lowercase (or perhaps camel notation, or anything that’s not all uppercase). Some will read this and cry out, “But according to XHTML we are supposed to put HTML elements in lowercase!” That is true, but it’s only true within the XHTML document itself. Within a style sheet no such requirement is made.
Not Just a Hat Rack - Worth a Look – September 2nd, 2010

September 2nd 2010 @ 4:19 pm #

[...] Single-Line vs Multi-Line CSS, plus TextMate tips – Solid argument for multi-line CSS. [...]