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!
39 responses to “Obsessive CSS Code Formatting: Opening and Closing Brackets”
Yes, one thing I learned from this series of articles is that, when it comes to CSS, sheer practicality often trumps expressive style. I also employ the single-line approach within compressed/optimized stylesheets, but prefer not to code that way. For my personal sites, where it’s all about personal expression and creativity, I take great pleasure in writing code as if it were poetry, with each line, jot and tittle carrying an intrinsic significance that transcends literal functionality. Each block of code is a verse, each declaration is a sentence, and the punctuation speaks for itself..
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.
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.
Good point about differences in code appearance from one platform to the next. There is also a great variety in how the code is displayed in different software applications. For example, I think Dreamweaver displays CSS very well, but I also enjoy working directly in notepad, which displays everything in monospace black and white text with no formatting whatsoever. For large stylesheets, I prefer Coda, Dreamweaver, or the like; but for smaller files and simple editing, notepad is perfect for me: crisp, clean, no-frills coding goodness. ;)
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.
Hi Thomas, excellent technique that I have recently adopted. Generally, multiple selectors do get their own line, although certain groups of selectors work just as well sharing the same line. I am finding that this “subordinate indentation” method works very well at keeping things organized, but it does take a little practice to get used to at first.
Using different CSS files for different types of styles is another useful organizational tool, although I don’t employ the method myself. As a performance optimization freak, I prefer to keep the number of server requests down to a minimum by keeping styles consolidated into one sheet per media type (i.e., one file for screen media, one for mobile styles, one for IE, etc.).
Great comment, btw — thanks for taking the time to share your technique! :)
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;}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.
Tabs suck.
@Dave Doolin: I disagree — I find them extremely useful. To each his own!
@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…
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. :)