#1 — Gabe

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.

#3 — Lee

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

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.

#6 — Gyrus

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

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.

#10 — Ben

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.

#12 — Jordan

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

#14 — Louis

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!

#16 — Kepler Gelotte

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

#18 — Jordan

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

#20 — rmaksim

method #2 + indents for internal elements of the parent blocks

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

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

#22 — Jeremy Johnson

I actually use a combination of #3 and #4. I use #3 if I have more than one class or ID that share the same styles or if a class/ID has more than 2 or three styles.

I use #4 if I have a group of similar classes/ID that belong to a group. For example if I have a sprite consisting of 4 images, I place them together in a group in the #4 method.

#24 — Louis

I changed my coding habits recently, and I guess here is the place to speak about it.

I switched from this to the one-lined declarations. I realised that I was actually spending more time locating the selectors than writing code. This is bad, so I tried the one-lined syntax and found it really confortable.

Also, it makes the structure of the CSS file clearer, as you can see in this screenshot.

#26 — Louis

That’s pretty much Wordpress’ slogan :)

Though, as beautiful as coding can be, I think real (litteral) poetry is a big step further in terms of difficuly.

#27 — SneakyWho_am_i

I’ve moved from method 3 to method 4, and I fall back on method 2 for long lines. No tabs, though because when I jump on my Windows/Linux box at work/home, everything looks a bit weird.

#29 — Thomas Ingram

I’m actually favoring a variation on the first format:

.content_primary {
       background-color: #ff9966;
       }
       .content_primary p,
       .content_primary a {
                     color: #006699;
                     }
/* ... */

The idea is to indent items to show the inheritance hierarchy. Also each identifier gets it’s own line. This method works very well for me to not have to work out what applies to what. And it makes it very easy to override specific items if I wish. On the downside the extra tabs do add a little bit of page weight. But even then it wouldn’t be difficult to whip up a script to compress the CSS after you roll out your site.

While I’m here, I also have been separating different properties into individual files. That is, all color declarations in one file, all typography styles in another et cetera. Then I wrote a simple script to include only the styles I need in one download. It didn’t take too long, and I love how compartmented my code is. Everything in its place.

Sorry for going long. I probably should have put this on my own site and linked to it.

#31 — Mark

I favour this, which I also use for my C# (sadly no longer, Microsoft have now decided that I can no longer format the code how I LIKE to read it and after one update to my VS 2008 it now formats my C# like method #1 - yes I know its C# not CSS but I do think that formatting for whatever language should be left to coders and not the corporations!!!)

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;
       }

#32 — Jordan

Just on the topic of Visual Studio’s so-called “smart” indentation: I would just like to rant a little about the bizarre, inconsistent, untidy and utterly unreadable indentation it enforces on inline VB code, essential when using the new MVC framework. It will happy increase the indention by twelve tabs from the last line for no good reason, and is apparently impossible to turn off.

I’m honestly about to hit my computer with a hammer. IDE developers, take note: programmers know what sort of indention rules they prefer, and what is most readable in a given situation. Provide some good defaults, by all means, but make them overridable or configurable—don’t just enforce your broken algorithms unilaterally.

#33 — Dave Doolin

Tabs suck.

#35 — Dave Doolin

@Jeff… yeah, I should have a j/k on that. I don’t like tabs myself at all, but I know I’m in the minority! I mostly suffer in silence…

#36 — PragmaTechie

I haven’t really used this but just to make your list complete ;) :

Selector
          {
          attr:val;
          attr:val;
}

Personally, I find 2 (method 2 of your post ) needs lesser keystrokes but method 1 is quicker even with more keystrokes. How’s that? You use adjacent keys subsequently and double-tap the Enter key. Here’s what I mean:

1 type the selector and a space;
2 press Shift and { }; (though this is 2 characters, it’s quick and you need to press Shift only once)
3 press <–, double tap Enter, <– again; (this is really a quick sequence since the Left Arrow and the Enter key are close to each other and you press Enter twice)
4 press Tab and type your declarations;
5 press Down Arrow and Enter;

you’re now ready for the next rule!

Method 3 is just as quick as 1. Instead of a space in step 1 above, you press Enter. But observing the motion of my hands, I still think 1 is quicker because my thumb is already resting on the Spacebar.

I think that if you write a rule sequentially (char by char), 2 is the quickest as it needs the least keystrokes but if you group the same keys and adjacent keys, 1 is quicker.

But sometimes, you spend a lot of time thinking about the declarations that any speed gain using this method would be negligible.

Just a beginner’s thoughts, no big deal. If I happen to be wrong, just ignore this. :)

#37 — 30YearDev

@Mark #31

Cannot believe this format (basically Whitesmith) was not mentioned earlier. This is easily the best bracing format that exists - for virtually all curly-brace languages, including C, C++, Java, PHP, etc.

Think about it from a usability/readability stance - of course matched braces need to align with each other. But they do NOT need to be floating out in the left margins, hogging up your attention that should be focused on the actual control structure and content!

Beyond that, it’s a much better match for the actual grammer of these languages. The braces are part of the statement inside the control, NOT part of the control ! i.e. the definition of an if statement is:
if ( condition )
statement;

it’s NOT
if ( condition )
{ statements };

The grammer of a statement block is: ::= { ? }
For more details, see any BNF description, such as: http://www.daimi.au.dk/dRegAut/JavaBNF.html

In the first case, virtually everyone would agree that the inner statement MUST be indented.

The inner statement can be a single statement, or one or more statements surrounded by { }. And in either case, the statement or statement block should be consistently indented from the “if” itself. This leads to more readable code as well as being more “properly” structured, from a language point of view.

If you think it’s odd, just try it. I guarantee that unless you’ve closed your mind to advancement you will find that it’s by far the easiest formatting to work with — once you’ve flushed the other garbage out of your head. Granted, this can be hard to do if you’re in a shop with poor code formatting standards, but you can try.