Obsessive CSS Code Formatting: Opening and Closing Brackets

Following my recent post on CSS code formatting, I was delightfully surprised to have received such insightful, enthusiastic feedback. Apparently, I am not the only person passionate about the subtle nuances involved with the formatting of CSS code. So, to continue the conversation, let’s explore several techniques for writing the opening and closing brackets of CSS declaration blocks.

Formatting method #1

I have seen this method used more than any other. The opening bracket appears on the same line as the selector and the closing bracket appears on its own line after the final property:

div#example_01 {
	padding: 3px;
	margin: 33px;
	width: 333px;
}
div#example_02 {
	padding: 3px;
	margin: 33px;
	width: 333px;
}
div#example_03 {
	padding: 3px;
	margin: 33px;
	width: 333px;
}

Standard stuff, maybe even a bit boring..? I don’t know. I tend to use this formatting method by default, although my technique is rapidly evolving to include a more sophisticated approach..

Formatting method #2

Recently I have been dabbling with this sexy little method. I love the way the closing bracket aligns neatly with the preceding declaration block:

div#example_01 {
	padding: 3px;
	margin: 33px;
	width: 333px;
	}
div#example_02 {
	padding: 3px;
	margin: 33px;
	width: 333px;
	}
div#example_03 {
	padding: 3px;
	margin: 33px;
	width: 333px;
	}

Of course, the major advantage to this technique is the improved readability of the various selectors. With no closing brackets cluttering things up, Locating target code is about as easy as it gets..

Formatting method #3

Although I have never used this method, I can certainly understand why people continue to use it. Every now and then, I will encounter a snippet of CSS that places the opening bracket on the line immediately beneath the selector:

div#example_01 
{
	padding: 3px;
	margin: 33px;
	width: 333px;
}
div#example_02 
{
	padding: 3px;
	margin: 33px;
	width: 333px;
}
div#example_03 
{
	padding: 3px;
	margin: 33px;
	width: 333px;
}

I think the idea here is to facilitate the readability of the code, however there is something that just seems out of place with that opening bracket. On a positive note, the uniformity of the bracket placement increases overall consistency and brings additional order to the document.

Formatting method #4

Last and quite possibly least, is the infamous “single-line” technique! For the more practical-minded folk out there, this method easily trumps the others with its sheer efficiency:

div#example_01 { padding: 3px; margin: 33px; width: 333px; }
div#example_02 { padding: 3px; margin: 33px; width: 333px; }
div#example_03 { padding: 3px; margin: 33px; width: 333px; }

Sure, this method looks great here, with the deliberately identical example declarations, but out in the wild, stylesheets employing the ‘ol single-line approach appear convoluted, complicated, and crowded. Yet, to those looking to squeeze that extra 5Kb out of their total bandwidth, the benefits of this technique are clear.

Share your thoughts

What is your preferred method for writing CSS brackets? Do you use one of the above methods, or something else? Share your thoughts!

About this article

This is article #535, posted by Perishable on Tuesday, April 22, 2008 @ 07:47am. Categorized as Presentation, and tagged with css, Presentation, streamline, tips. Updated on April 23, 2008. Visited 6365 times. 20 Responses »

Bookmark • Trackback • Comment • Subscribe • Explore

« How to Block Proxy Servers via htaccess • Up • Top Ten Pink Floyd Songs for Audiophiles »

20 Responses

1 • April 22, 2008 at 9:00 am — Gabe says:

I’m a deviation of “option #1″. I put the opening bracket on the line of the selector, but I don’t have any white space between said bracket and the selector.

2 • April 22, 2008 at 9:11 am — Perishable says:

What? No white space before the bracket? What about a blank space between the various properties and their values, for example:

padding: 33px;

..or do you write:

padding:33px;

and why?

3 • April 22, 2008 at 11:14 am — Lee says:

I use method 3.

I’m a developer (C# currently) and my code is formatted like that as well. In code you have a lot of nested sections so lining up the braces of each indented section helps make things easier to read.

So when I started creating stylesheets, I just used that method naturally since it mirrored what I was doing in code.

I agree that method 1 is most common in the wild.

For what it’s worth, I’m not a big fan of method 2. Probably because it’s so different from method 3. I’m accustomed to scanning the left side of a section for brackets - with method 2, I see nothing on the left side!

4 • April 22, 2008 at 12:33 pm — chuck says:

ive been using method #2 for the last month or so and love it. works great with indenting children selectors and quickly finding the code.

before that i was a #1 guy.

5 • April 22, 2008 at 2:28 pm — Perishable says:

My CSS formatting preferences have changed and continue to do so. For the first couple of years, I was also a #1 man to the core. Then, as my style evolved, I began to lean toward the second method, and currently choose it whenever possible. Given that trend, I would not be surprised to see my bracketing preferences change yet again at some point in the future. Oddly enough, I think the next logical evolutionary step would be #3, as it further facilitates easy reading (or so it seems). Bottom line? It may all be a matter of sheer practicality after all!

6 • April 22, 2008 at 3:50 pm — Gyrus says:

I used to think #4 was insane, but now it’s how I do all my CSS. I find it much more “readable” in the sense that scrolling vertically through CSS files formatted using #1, #2 or #3 - even when you’re pretty good as efficient use of selectors etc. - can be a bewildering experience, to flip from one section to another.

After a little while a doing this for the above benefit, I found it very easy to read horizontally like this.

I try to keep block-level rules near the start and inline rules towards the end. And I use that logic as far as I can, e.g. float goes before margin as it seems more general and less specific.

Past that, #1 makes most sense. I always format braces like that, e.g. in JS functions. When if/elses and loops are nested, I find this style much easier to scan for matching.

7 • April 22, 2008 at 5:00 pm — Louis says:

I think the formatting in this case is only a matter of taste. I personaly find myself very comfortable with the following syntax.

div#example_01{
padding: 3px;
margin: 33px;
width: 333px;
}

div#example_02{
padding: 3px;
margin: 33px;
width: 333px;
}

div#example_03{
padding: 3px;
margin: 33px;
width: 333px;
}

Yes, no indenting of the properties, and spaces between “blocks”.

Though, I’m a little disturbed by this sentence — speaking about the Formatting method #4.

Yet, to those looking to squeeze that extra 5Kb out of their total bandwidth, the benefits of this technique are clear.

I think that on the production side, you should always serve compacted & compressed content, because performance has such an impact on the visitor experience.

8 • April 22, 2008 at 5:52 pm — Perishable says:

@Gyrus: I agree that single-line CSS blocks are an excellent way to save space. I often “punctuate” certain regions of method-#2-formatted code with single-line blocks, especially for single-property declarations. I also use single lines when identical/similar blocks of code appear sequentially, for example:

h1 { font-size: 3.0em; }
h2 { font-size: 2.0em; }
h3 { font-size: 1.7em; }
h4 { font-size: 1.3em; }

..or:

#g1 { background: url(g1_.jpg) no-repeat center center; }
#g2 { background: url(g2_.jpg) no-repeat center center; }
#g3 { background: url(g3_.jpg) no-repeat center center; }
#g4 { background: url(g4_.jpg) no-repeat center center; }

..and then continue above and below such lines with #1 or #2 formatting. To me, including regions of single-line code in this manner improves the overall flow and readability of the document. And of course, single-spacing between each segment (as shown in the example) is a must! ;)

9 • April 22, 2008 at 6:10 pm — Perishable says:

@Louis: yes indeed, that is another fine example. Speaking strictly about opening and closing brackets, your technique seems like a modification of the first, most popular method. The opening bracket is on the same line as the selector (sans space), and the closing bracket is placed after the last declaration block, aligned with the first character of the selector. The fact that you don’t indent the declaration blocks themselves is also quite remarkable. Personally, I would find it difficult to locate the various selectors while scanning the document, but if it works well for you, then so be it! ;)

As for serving compressed and optimized code whenever possible, I wholeheartedly agree. I guess the point I was trying to make is that compression may not be necessary when writing CSS code in strict, single-line fashion. These documents are already relatively optimized such that further reduction in file size may prove negligible.

10 • April 23, 2008 at 1:52 am — Ben says:

I use method 4, with the added difference of no spaces after the colon. Removing this unnecessary space makes the individual parameters easier to locate.

For me the main issue is finding the class/ID, not finding the parameter within each one.

Out of the first 3, method 2 would be my choice. But the problem with all these for me is the sheer amount of scrolling involved in a large site’s CSS file. With method 4 you’re looking at only 2-4 screen heights max.

11 • April 23, 2008 at 8:44 am — Perishable says:

Looks like the fourth (single-line) method is more common than I had previously thought. Ben makes a good point about the readability of the code using this technique: locating the selectors is generally more important than jumping immediately to some specific declaration block. With the single-line approach, the selectors are generally neatly aligned to the left side of the screen, thereby facilitating their recognition. I have also seen CSS code using the single-line technique whereby reading is made even easier via skipped lines between code blocks and indentation of various subordinate blocks.

12 • April 25, 2008 at 11:54 am — Jordan says:

Method one all the way for me, with a space between the selector and opening brace. This is probably because it’s how I use curly braces in programming, so it just looks natural.

Recalling how you organize your CSS properties, I can see one reason you might prefer method two: visually, it would continue the wavy diagonal line along the right edge of your declaration block. What do you think?

Method three is the way one of my housemates formats all his code, including CSS. I don’t really like it, though… For some reason, it gives me the feeling that my code is slipping down the document like raindrops on a car window! However, the code is eminently readable, so it’s a defensible technique.

The fourth method is fine for single-property declarations or compressing files for the browser, but simply impossible for code that anyone else is ever meant to read! (Incidentally, when I do want to compress a stylesheet, I usually strip out all unnecessary whitespace, including any space preceding or following braces, colons and semicolons.)

13 • April 27, 2008 at 9:39 am — Perishable says:

Hi Jordan :)

Absolutely correct about your second point — that is precisely the reason I find the second formatting method so appealing. And, to continue along that same line of reasoning, method-2 brackets increase uniformity throughout the document by lining up with the left-most characters specified in the declaration blocks. The funny thing is, I had not been able to elucidate my preference for this method until reading about it in your comment. Thanks! ;)

I totally agree about the third technique, although a potentially useful formatting method, something about it just looks broken. I am so familiar with seeing the opening brackets of CSS code placed on the same line as the selector, that it almost looks ridiculous to see them placed on the next line. But again, it is a sound technique that may prove beneficial in the future.

As for method four, again, all great points. Although I employ single-line code blocks every now and then (as punctuation, for similar blocks, etc.), I find it impossible to design even moderately sized websites using this technique. By the way, I would be very interested in knowing which CSS compressor/optimizer you use to strip out all of the unnecessary elements in your CSS documents..

14 • April 27, 2008 at 11:07 am — Louis says:

The best compressor I’ve found that strip all the unnecessary spaces and co, is… your code editor. Just search and replace all “, ” with “,” for example, and so on.

You can also use YUI Compressor, it’s the best JS/CSS compressor out there in my opinion, and it has this really cool feature of letting you decide the max lenght of lines (one lined css file may have an impact on the CPU, and are a pain to edit.

It also does character encoding, which is great. UTF-8 FTW!

15 • April 28, 2008 at 7:47 am — Perishable says:

Yes of course! The humble code editor would indeed do the job (it may take a little longer, but hey, whatever!).. in fact, I use various text/code editors to do this sort of “find and replace” all the time, just never occurred to me to use this method to optimize an entire CSS file. In any case, thanks for the tips, especially for YUI compressor; I will definitely be checking it out (for both CSS and JavaScript).

UTF-8 — WOOT!!

16 • May 6, 2008 at 6:57 pm — Kepler Gelotte says:

I am a programmer as well and use formatting method #3 for a few reasons:

1) It makes it painfully obvious when you forgot an opening/closing bracket. I have spent too many hours debugging code only to find my “if” statement didn’t have a curly brace at the end (That was in C code not CSS).

2) I use vi, so the ]] and [[ character sequences will jump to the next and previous open curly brace (begin block) only if it is the first character of the line.

Finally I compress and gzip my CSS using some apache/PHP code I wrote. This code compresses without my having to modify how I write my CSS. You can download it for free at http://www.coolphptools.com/dynamic_css

17 • May 7, 2008 at 9:15 am — Perishable says:

Wow, looks like #3 is winning by a landslide, apparently due to its sheer practicality (not surprising, given our money-mad market-driven economy). As you say, placing brackets on their own line makes it virtually impossible to forget or misplace them, especially when using a facilitative editor such as vi to expedite the process (note to self: check out vi). Some great points, Kepler, thanks for chiming in, and thanks for sharing your dynamic CSS compressor. I have downloaded it and will definitely be giving it a spin! ;)

18 • May 9, 2008 at 5:48 pm — Jordan says:

Robson’s CSS compressor gives me the best results. I’ve tested a few, and this one is simply merciless at squeezing out every unnecessary character. (It supports UTF-8, too.)

19 • May 12, 2008 at 10:30 am — Perishable says:

Thanks for the followup, Jordan. I have bookmarked Robson’s CSS Compressor and will definitely be taking it for a spin! Cheers ;)

Drop a comment

Trackbacks / Pingbacks

Catch Design » Blog Archive » How do you format your CSS?

3G Blacklist finally unleashed!

Perishable Press