Latest TweetsVerify any search engine or visitor via CLI Forward-Reverse Lookup perishablepress.com/cli-forwar…
Perishable Press

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!

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
39 responses
  1. 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. Jeff Starr

    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. 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. 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. Jeff Starr

    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. 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. 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. Jeff Starr

    @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. Jeff Starr

    @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. 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. Jeff Starr

    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. 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.)

[ Comments are closed for this post ]