Obsessive CSS Code Formatting: Opening and Closing Brackets

39 responses to “Obsessive CSS Code Formatting: Opening and Closing Brackets”

1. 

   Gabe 2008/04/22 9:00 am

   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. 

   Perishable 2008/04/22 9:11 am • Post Author

   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. 

   Lee 2008/04/22 11:14 am

   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. 

   chuck 2008/04/22 12:33 pm

   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. 

   Perishable 2008/04/22 2:28 pm • Post Author

   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. 

   Gyrus 2008/04/22 3:50 pm

   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. 

   Louis 2008/04/22 5:00 pm

   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. 

   Perishable 2008/04/22 5:52 pm • Post Author

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

   Perishable 2008/04/22 6:10 pm • Post Author

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

    Ben 2008/04/23 1:52 am

    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. 

    Perishable 2008/04/23 8:44 am • Post Author

    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. 

    Jordan 2008/04/25 11:54 am

    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. Something to add? Let me know.