Sickdesigner
The sickness is spreading
The definitive guide to formatting CSS
As web designers, we like certain things done a certain way and the way we write our CSS is probably at the top of that list. So today I’ll try to show you a few ways to write better CSS, not just for yourself, but also for others.
Right off the bat, let me say that I do not proclaim (not anymore) that there’s a right way or a wrong way to format your CSS. I’ve come to the (hopefully mature) conclusion that the way one formats styles should be based on the type of project at hand. And this the basis of this post.
Gone are the days of small, static websites that take about a day to code and have less than 500 lines of CSS in them. Nowadays, we find ourselves working with blogs, CMSs, frameworks, web applications, web shops and generally huge friggin projects. The CSS we write today is almost never under 1000 lines and when you’re dealing with that much code, you need to be able to maintain it easily.
Most web designers have their own, preferred, way of writing. And they stick to it no matter what. I used to do that myself. But the more diverse your projects are, the more you’ll start to notice the pitfalls of your preferred technique. And then you might realize that your own, personal, style of writing stylesheets isn’t really that important, when it hinders to the maintainability of the project.
I think it goes without saying that in this post I will completely avoid the possibility of “inline” and “in head” styles. These two options aren’t really an option because they both mean polluting your markup, so I’ll politely tell them to get the fudge out of the equation. If any of you have a problem with that, take it down to the comments section, where complaints are more than welcomed.
I’ve got a system here, so, we’ll start with the big stuff (file management) and end with the really small stuff (the curly bracket – quite poetically).
Single file vs multiple files
The single file approach, like the code above, is most suitable for small projects. I’d say somewhere under 1500 lines of CSS is the limit, at least for me. As long as you keep your styles organized, this approach should work out ok.
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html>
- <head>
- <link rel="stylesheet" href="css/reset.css" type="text/css" media="screen" />
- <link rel="stylesheet" href="css/structure.css" type="text/css" media="screen" />
- <link rel="stylesheet" href="css/type.css" type="text/css" media="screen" />
- <link rel="stylesheet" href="css/colors.css" type="text/css" media="screen" />
- </head>
- <body>
- ...
- </body>
- </html>
The multiple file approach is a good choice when working on larger, more complex projects. It’s also a good idea to use this approach when you have a project that will have a lot of updates. Being organized like this and keeping different sections separate can make your job a lot easier.
- @import url('css/reset.css');
- @import url('css/structure.css');
- @import url('css/colors.css');
- @import url('css/typography.css');
The direct approach to multiple stylesheets isn’t the only option. You can use the @import rule to put together your multiple CSS files within a single, main stylesheet.
The downside with using multiple stylesheets is that they add to the number of HTTP requests made for the page, which slows down your page load times a bit. I wouldn’t worry too much about it though. Most of the time you can get away with it and still have good performance on your pages. Compared with database queries, javascript calls or even image load, the downtime caused by large CSS files is, mostly, insignificant.
If you’re totally anal-retentive about page load times, however, you can use a stylesheet minifier to decrease the size of your CSS files. More often than not, you can slim them down to at least 60% of their original size.
To indent or not to indent
- p{ font: normal normal 1.2em Arial, Verdana, Tahoma, sans-serif; }
- p span{ color: tan; }
Not indenting your CSS selectors at all is usually a bad idea and I really can’t see one upside to it. So don’t be a naughty Nancy and press that Tab key every now and then.
- #block{ float: left; margin: 0 20px 0 0; width: 200px; }
- p{ font: normal normal 1.2em Arial, Verdana, Tahoma, sans-serif; }
- p span{ color: tan; }
- p em{ font-variant: small-caps; }
You can indent in chunks. That is to say, sections that are related directly are indented (like the span and em as children of the p tag), but unrelated ones stay unindented (like the block id and p tag). This could work, as you keep your file size small, while still having the legibility and organization specific to the indented style. It’s a sort of hybrid option.
- body{ margin:0; padding:0 }
- #wrap{ position: relative; margin: 0 auto; width: 900px; }
- #left{ float: left; width: 66%; }
- #left .inner{ padding: 20px; }
Fully indented text has the best legibility and is, to many people, myself included, the easiest way to maintain your stylesheets. The downside is that styles get big pretty fast so it’s a good idea to combine this style of writing with multiple file stylesheets.
Single line vs multiple lines
- #left{ float: left; width: 66%; }
- #right{ float: right; width: 33%; border: 1px solid #333; background: #cecece; font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }
Single line CSS attributes are a very concise way of writing your styles, but they have the disadvantage of becoming harder to read as the attributes add up. The id left in the example above is an example of an easy to read and concise set of attributes, whereas the id right, with it’s many attributes is a huge pain to figure out, especially if you’re looking at the code a few months after it was written.
I found that many of the programmers I’ve worked with prefer single line CSS.
- #left{
- float: left;
- width: 66%; }
- #right{
- float: right;
- width: 33%;
- border: 1px solid #333;
- background: #cecece;
- font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }
The multiple line approach has it’s appeals: it’s easy to read, to edit and, subsequently, easy to maintain. The downside, of course, is the increased length of your stylesheets.
I found that many fellow web designers prefer this approach.
To alphabetize or not to ahlaiebtpze
- #right{
- background: #cecece; border: 1px solid #333; float: right; font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; width: 33%; }
I am a huge supporter of CSS alphabetization, so I may come off a bit subjective here, but I really do think it’s one of the best ways to format your stylesheets, especially when using the single line approach. That way, you can overcome the downside of many attributes becoming hard to read through, like in the example above.
- #right{
- float: right; background: #cecece; border: 1px solid #333; width: 33%; font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }
Alphabetizing takes time to get used to. It’s not the most intuitive and natural way of writing and it’s main downside is extra time spent on the CSS file. But, if you persist in this practice, you can develop your writing skills to such extent that it becomes natural to alphabetize.
The curliest of brackets
- #left{
- float: left;
- width: 66%; }
- #left{
- float: left;
- width: 66%;
- }
- #left{
- float: left;
- width: 66%;
- }
Should the closed curly bracket at the end of each selector be next to the last property, or on the next line? And should it be indented or not? Personally, I put the bracket next to the last property, to save some space. But that’s just me, this one’s totally open to discussion.
A few examples
- body{margin:0;padding:0}
- #wrap{width:900px;position:absolute}
- #left{width:66%;float:left}
- #right{width:33%; float:right}
- .inner{padding:20px}
I like to call this the programmer-friendly approach (though I’m sure this doesn’t apply to all programmers). Single line, chunky indenting, no alphabetization, no extra spaces, curly brackets at the end of the line. And it looks really, really crammed.
- body{
- margin : 0;
- padding : 0;
- }
- #wrap{
- position : absolute;
- width : 900px;
- }
- #left{
- float : left;
- width : 66%;
- }
- #right{
- float : right;
- width : 33%;
- }
- .inner{
- padding : 20px;
- }
I call this one the over-achiever approach. Multiple lines, full indenting throughout, alphabetized, curly bracket on a new line and indented and bonus points for super indenting the properties to be one above the other. And it is way to spaced out.
Whichever way you decide to approach your CSS stylesheet “writing skills”, be aware of the pitfalls of each one and settle on a way that fits your project’s needs, not your personal preference.
I like using single-line CSS, but don’t indent at all. There’s a space between every word (and curly bracket/selector) so it’s not like the programmer friendly approach.
As much as the alphabetizing makes sense, it’s not ideal. It makes more sense to have a certain order to the properties, like first is position, than margin/padding, than text styling (font, text alignment, etc.), background, and lastly is borders (mostly due to CSS3 taking up a lot of space at the moment.
Great article, here’s one of my CSS files http://cdn.myunv.com/css/uecore.css
“Your programming is showing”
(paraphrasing James White)
If your system works well for you (and your team, if that’s the case) then you shouldn’t give it up, no matter what a blog post tells you. It’s always good to look around and see alternatives, but, at the end of the day, if your own system is the one that’s more efficient for you, then that’s what you should stick with.
I agree for the most part, except I like having the closing curly brace on a line by itself, that way it’s easier to add/delete properties without worrying about deleting/overshooting the curly brace when you happen to want to delete the last property of a class, or add a new property to the end.
My opinion is easy – you can use e.g. PSPAD (my favourite code editor) and use “format CSS” function and you can inline format or indent format, so you can write with full indent and when you save, you just do “format as one line no ident”, so no spaces extra.
P.S.: but imho it does not much care – if you have 1024 spaces more, it means you go got 1 kB more, so very tiny bit comparing event the simplest page graphics
I can’t tell you how many times formatting my CSS has saved my life. I can almost scan and find any element in seconds, event without using CTRL+F!!
Always find it interesting to see how other people code. Personally I like the multi-line and indent approach, purely because I find it much easier to read. Think my habit to indent has come from a programming background.
Great article!
Radu, I think you missed out the discussion about the terminating semicolon in a declaration block.
While the spec defines a grammar – and dictates to leave it out – common practice is to put it in here and there at will. However, the validator doesn’t complain about it.
Your examples are showing both ways – and an additional version in the last #right declaration that leaves out a mandatory semicolon…
… but hey, it’s your blog, you’re allowed to do that
@Steffen: Yep, you’re right, I did miss a mandatory semicolon. Thanks for pointing that out! It’s fixed now
I avoided the whole semicolon or not discussion because it’s a mandatory part of CSS grammar, so whether or not one adds a semicolon to the end of a block is really up to the writer and doesn’t help with maintainability.
I find one line CSS is personally easier for me to read. It also helps that I’m working on a 22″ monitor. I also don’t like indenting my code because my eyes tend to skip over attributes when searching for them, since I look all the way to the left. Organizing CSS is definitely more of a personal preference kind of deal. There’s really no right or wrong way, as long as you have some kind of organization in place.
Well your last name is what really gave it away
Very interesting. Some of these methods I’ve never even thought of. I think you usually stick with the method you used when you first start building websites using CSS, at least thats how it is for me.
P.s. With a name like Radu you must be Romanian! NOROC!
@jon: thanks for the comment. While Radu is, natively, a slavic name, yes, you’re right, I am Romanian.
@Radu Chelariu:
But this is how I know exactly where to look for what. Without scrolling. Not that I have anything against scrolling tough. 
Yeah, I knew that I was the only one.
Guilty as charged, I am a Firebug freak. It’s an amazing tool, saves me a tons of time with its live preview of css changes.
I’ve just been going trough some of my big css files and it may seem cumbersome on first sight, but I’ts actually quite readable.
I clearly separate sections (header, nav, body, sidebar footer etc.) with comments, and I don’t alphabetize, but prioritize rules. I always put positioning rules first (margin, padding, width, height, floats, etc.), and styling (fonts, colors, backgrounds, etc.) rules after that. Well, this does sound crammed.
I guess I fall into your programmer-friendly category. I’m just a little bit more friendly than the one in your example.
Oh, and just to make it clear, this is just my css preference. In php and JavaScript/jQuery I do indent and put all brackets on new lines.
@Jason: I’m glad you found the article useful. Yeah, alphabetizing is definitely something to try. I think it can really clear things up more than any other practice. But that’s just me.
I have found myself using the multiple line aproach with having the ending bracket having it’s own line. I like the idea you had with alphabitizing. I am going to have to give that a try sometime, thanks!
@Bill Chambers: I have the same approach as you about it and it’s been a whole lot easier and hassle free since I decided to stop being such a snob about the way I format my styles. And somehow, it feels like I broadened my understanding of CSS since I’ve done so. Perhaps it’s just psychological
@Shikeb Ali: Oh yeah, wordpress websites and single-line CSS are not a good match. So, so true!
@Jean Minnaar: theme CSS would be an addendum to the multiple file format. And while it is a very good practice, it only applies to small percentage of projects. It’s good to know, though, so thanks for chiming in!
@earthdesigner: Tatiii!!!! Oh, I still have my weirdo tech questions, but as you thought a long time ago, “Hit your head on the wall until you figure it out”.
Actually, to extend your metaphor, non-indentation feels like a tab (faster to read, but not very meaningful if you don’t know the song already) while indentation feels like sheet music (a bit more complicated but your timing is right there in front of you)
Hey Radu! Nice post! For me, it really depends on the job. I like to space things out a bit to make it really easy to read. I also group everything. It also depends on the project, size, if I am working with others etc. Anyway, rockin post!
Nice article. I think most web designers prefer code in multiline css technique as its really helpful when you are looking for something to change and it do look neat.
Single line code is good for small websites but if you are coding a wordpress theme, things will go little messy.
These are all great tips for designers, especially new ones, but I would also suggest to add something about base CSS vs theme CSS. Organizing CSS in this manner can allow one to create templates based on one design. The overall flow would be the same from the base, but the theme (colors, images) can be easily changed creating a new look with minimal effort. Really love the blog though.
Being my 1st comment here I want to congratulate you for your blog, thank you for the great content and the heart & soul you’re putting in, and nevertheless that I miss your challenging tech questions
Back on subject, which remains a ‘hot’ topic, I see the indenting good only in html and not necessary in css. If you cleverly indent and tag in html, the contextual selectors do the same in css. When I see “#header h1″ in css I know there’s a with a inside it.
To conclude my point of view let’s assume an exaggerated parallel: that we can write a musical score in the same way we write css. Now, how will you play by an “over-achiever approach” score?
Great posts! Keep’em coming!
That..is a bucket load of comments. But everybody deserves an answer, so here goes:
@DesignInformer: exactly; it’s about what works for you and your team and the project at hand.
@Anthony Hortin: you’re a god amongst programmers then, and we salute you wholeheartedly.
@MCB Web Design: I agree, and as I’ve pointed out at the beginning of the post, if you really need to, you can use a minifier.
@Takingweb: thanks for the fav! I try not to think of them as guidelines as much as construction blocks. You build the structure your project needs using the blocks that serve your purpose best. Yeah, I like metaphores, ok?
@Igniatovic Nikola: I ran into the same problem time and time again. Sometimes I’d give in to their single-line-ess, but other times I would push for multi-line. In time I’ve learned that it’s not what I fancy that matters, but what’s best for the project. And what’s best for the project is best for us, right?
@sajjadul farooque robin: YSlow is kind of a weird tool, if you don’t configure it a bit. You can set what kind of project you’re working on, and depending on that, it will adjust it’s limits. For example, on a blog, multiple CSS files pass ok.
@Alfredo Matos: Good point. That’s a bonus for keeping the bracket on the next line. Thanks!
@Julian Nicholls: I’ve seen this approach a few times with other designers but have always found the combination a bit distracting and hard to skim. It’s a good tip, though, for anyone that has no trouble reading this system.
@Niels Matthijs: as far as I know, not all code editors have an option to color code subjectively, so your tip, although valid, is only applicable to some editors.
I can see where you’re coming from. There seems to be a kind of psychological delight to scrolling through hundreds of lines of code. Hey, I’m guilty too! Some people don’t find multiple files cumbersome. In fact, if you keep all of them opened (and most of the time there are about 3 files) you can easily switch with a keyboard shortcut. Thanks for the tips on the comments usability, I’ll take them into consideration! The post button problem was probably at your end, since it’s peachy fine for everyone else. Perhaps the page didn’t load fully. Browsers, right? 
@Henrik Kjelsberg: I agree, most of the time, something like the over-achiever approach doesn’t pose any problems (plus, it can look pretty impressive right?) but when you’re dealing with a large project that has a short deadline, every second spent formatting code just for the sake of it looking pretty is time wasted.
@Thomas Craig Consulting: it’s an interesting idea but I’m not sure what the upper limit for CSS overwrites is until browsers start to become a bit sluggish on page load. I was talking to a programmer friend just today about this. It’s unclear how browsers perform when you’re overwriting say 200 selectors or maybe overwriting 10 selectors 20 times, for example. Of course a lot of factors come in, but I guess it’s something to think about.
@Duncan Beattie: good approach! I bet most of the time this saves a lot of time on updates. But what do you do when the client demands structural changes? As far as I know, a un-minifier has yet to be invented
@Zach Schneider: of course comments are always a good idea, no matter what language you’re writing in. I don’t care if you write in C# or HTML or friggin COBOL (that’s a joke, guys), comments are a must. But comments have nothing to do with formatting your styles. Comments, to me, have to follow the CSS format of choice, not influence it.
@Thom Lohman:
javascript without identation is, for me as well, like looking for a needle in a haystack. A big, messy, strange haystack. Eliminating the linebreaks is a good idea if you keep the ending bracket on the next line; that way you save space and don’t have to worry about deleting it when getting rid of the last attribute and property, like Alfredo Matos mentioned below.
@Zoran Jambor: hey, everybody! we’ve go one of “those guys” here
just kidding. But, seriously, how do you read through it? Come clean, are you a Firebug freak?
@Marco Pivetta: as I said in the post, “the downtime caused by large CSS files is, mostly, insignificant.” so, there wasn’t really an argument there, it was a consideration point for all those that are overly concerned with file sizes. So, yeah, I agree it’s all about editing faster, easier and better.
@Aaron Blakeley: I think most of us like to read through our stylesheets like a story, because, as designer, we are, in a way, telling a story. It’s a beautiful metaphor and I equally congratulate you for it and despise you for thinking of it before I did. Sarcasm +1 for me
@Elf M. Sternberg: Cool, Aaron started as a designer and went into programming, you started as a programmer and moved into design. How poetic! LessCSS is, indeed, an interesing solution, but the fact that it implies programming sticking it’s fingers in styling is a downer for most web designers. But for your background in programming, it must feel right at home, no?
@Neil Monroe: I don’t know about you, but I find the whole “deployment” issue quite the nuissance 90% of projects. Sure, the really huge web apps that lean on every extra kilobyte do benefit from this approach, but most of the time, it’s just overkill as you’re not really lowering the page load times noticeably.
@Jasper: Thanks, apprently I don’t suck that bad
Jasper…meet Elf (he commented below). He uses LessCSS too. Be friends 
And another Sarcasm +1 for me.
Just for the record: I’m not proclaiming to know the perfect way to format your CSS, the point of the article was to break down a set of decisions which you can mix’n'match specifically for your projects. I’m a ferm non-believer in a fool-proof, universal, perfect way to format CSS.
That being said, my way is the perfect way
Wow, really like this post!
I also think the design of this site is terrific!
A very intuitive way to write CSS is LessCSS ( http://www.lesscss.org )
It’s a pity it removes comments in the final css file, but it’s still great!
Everyone should find their own best practices in what works for them, but I have found that working with multiple files helps keep the CSS rules categorized better and therefore easier to find and edit later.
However, I also agree with MCB Web Design about not using CSS minification until project deployment. Your code should be as easy to read when developing. Don’t worry about spaces or newlines. These can all be removed when you’re ready for production.
Combining all the CSS files together as one before minifying is a good idea to help keep the number of requests lower.
Adding good commenting to your CSS code is a must for me, too. It helps a lot when quickly browsing through a long CSS file. Comments can all be removed with a minifyer as well.
As a programmer who moved into design, I’ll say that I’ve always used multi-line and I’ve always indented. I also am fond of CSS Systems, but what has really made my work joyful is the discovery of Leaner CSS, an automated meta-framework that allows for hierarchal descriptions of CSS.
CSS frustrates programmers because it’s completely flat: every description describes a single kind of element, whereas HTML is containerized, and may contain many kinds of elements. LessCSS makes CSS conceptually resemble your HTML, and that makes it so much better.
To preface this I got my start in design and added programing to my skill set. I personally write single line css. and group like elements together. It saves time when scrolling through and looking for an offending style. I really have no problem reading it. Different strokes for different folks I guess. I find the that reading the single line is like reading a story. First the paragraph put on color #FFFFF then it changed to bold …. you get the idea.
Nice one, but minifiers make the entire file-size argumentations useless… So the best solution should be the one that makes editing faster
I started as multiliner, but moved to singleline approach.
I find singleline css files lot easier to maintain; it’s just frustrating to scroll trough large files to find something.
Never used indenting though, this just doesn’t work for me.
Good point about the propensity for programmers to adopt a single-line approach. I, on the other hand, cannot (cannot cannot) stand CSS written on one line–it reminds me of javascript that’s written without indentation. I tend toward the “overachiever” but have recently started eliminating the extra linebreaks.
Great post as a Web Developer I do the multiline for faster debugging. There was something that I do that I didn’t see in your post though. I like to write in comments/ documentation about particular locations or sections in the site. This helps me later on when I go back to it or need to pass it off to another developer.
>> Niels: If your css is 1000+ single-lines, you probably have a lot of repetition or bad code in there.
Hmmm, not really. But I do tend to work on bigger projects. Usually ranging from 30-40 different page templates. The more components you have, the more css is required.
2 css files – grid .css to take care of layout and site.css for site specific styles. The grid file is rarely touched so it’s minified, but the site.css is always multiline with curlies on a new line with no indent.
Great post, I like to separate my styles into multiple files this allows for greater customization at the presentation layer as your last file will override any previous classifications. Great for multiple color/design options on uniform structure.
I prefer something like your over-achiever approach really. It’s not really that much more work with the right editor and the benefits are many.
1. As MCB mentioned – file merging tools usually works line by line.
2. Commenting out parameters for testing is a breeze.
3. Correct indentation makes it possible to collapse/expand blocks of code.
4. You can comment parameters & still have it be easy on the eyes.
Niels: If your css is 1000+ single-lines, you probably have a lot of repetition or bad code in there.
Never really understood the need to indent selectors. If you use good color coding than not indenting the selectors will form a visual triangle of selectors.
You start with the shortest base class for one of your component, then go deeper for each dom level. Superclear, but indentation destroys this.
As for multiline css, I like to scroll through my css files. With 1000+ single lines for most of my projects, can’t even start to think about the vertical size if I put each property on a single line.
As for multiple files, I simply hate them. Switching/finding files takes me way longer than scrolling to the correct section in my css file.
Just my two cents
PS: comment form could move along down the comments section if you scroll down, I was lost there for a moment. Also, it would be nicer if the labels on the input were visible all the time. I like to tab through forms, so I keep missing what to enter
(oh, and your post button is completely gone here. Background image isn’t showing)
My 2c that I found an intersting suggestion, I wish I could remember where.
Single (and perhaps 2) item CSS on one line, e.g.
p#right { float: right }
and multi-item CSS on multi-lines, e.g.
img.right
{
float: right;
margin-left: 10px;
margin-bottom: 10px;
}
In the curliest brackets section, if you tend to use a shortcut oriented text/code editor, deleting the last property leads to deleting the closing bracket – extra work and potential hazard.
Really a nice article, Personally I am a programmer, but worked with lot of designers. Of them, your styling approach is among them which I like. I tried also code css in my free time. But single file css actually pass YSLOW test
, Nice One.
Nice post. I mainly do design and html. Not much real coding. The programmers here whenever i aint doing the css use the one line aproach. Personally i find it much easier to update and edit by using multiple lines for each style. But hey..
Each to their style
great article!…always try to followes these guide-lines….
add to fav!!!
I’ve always wrote multi-line CSS. One of the disadvantages of single-line CSS is you can’t use it in source-control systems; if you need smaller file sizes in CSS files then minimize before deploying.
Nice roundup! Even though my background is more development (as opposed to design) I prefer the multiple line approach, for readability. Oh and it goes without saying, curly brackets on the next line, not indented. I’m a firm believer that the closing bracket/brace should line up nicely with the start of the line that opened them.
Really nice breakdown. I tend to format my CSS a little bit differently than your approach. But it’s all about what works for the individual. Nice post!