Just to clarify beforehand, this article does not constitute an argument in favour of using multi-line CSS blocks over single-line CSS blocks.
But once in a while I peek at people’s CSS code, or try to follow along with a tutorial discussing some CSS topics, and notice that the CSS isn’t very easy to scan through, and the main problem is often white space, or you could say “breathing room”.
So, I’m going to explain here how I think CSS should be laid out (mostly using examples that incorporate multi-line blocks) for easier readability and scannability.
Space Between Declaration Blocks
The first thing that I think improves CSS readability is allowing an empty line between declaration blocks, so the blocks don’t morph into one another. Here are two contrasting examples:
This is good:
.content {
width: 600px;
color: #fff;
float: left;
border: solid 1px #ccc;
}
.sidebar {
width: 360px;
float: left;
border: solid 1px #ccc;
}
This is not good:
.content {
width: 600px;
color: #fff;
float: left;
border: solid 1px #ccc;
}
.sidebar {
width: 360px;
float: left;
border: solid 1px #ccc;
}
The only difference in the second example is the missing empty line between the declaration blocks. Okay, it’s not that big of a deal, I know, but when you scan a large CSS file, I think it makes it easier to take in if each block is followed by an empty line.
Space Between the Selector and the Curly Brace
This is another small spacing issue, but again, it helps keep things looking clean and uncluttered. Here’s what I mean:
This is not good:
.content{
width: 600px;
color: #fff;
float: left;
border: solid 1px #ccc;
}
.sidebar{
width: 360px;
float: left;
border: solid 1px #ccc;
}
Is it a little more difficult to read without the space before the first curly brace? Possibly. Maybe I’m just too picky, but in my opinion, when I scan a CSS file that has no space between the selector and curly brace, it almost looks like all the first curly braces are missing.
Space After Your Colon
Yes, I once announced in a business meeting (no joke) that the other developers needed to have a space after their colon. We laughed until our sides ached. But seriously, this is probably the most important way to ensure your CSS is readable and scannable. Look at the code below:
This is not good:
.content {
width:600px;
color:#fff;
float:left;
border:solid 1px #ccc;
}
.sidebar {
width:360px;
float:left;
border:solid 1px #ccc;
}
I don’t care what anyone says — to me, that example is a mess. Even if you ignore the other suggestions, please follow this one and put a space after your colon. And stop giggling.
All Suggestions Combined
And just to overemphasize the point, here are two contrasting examples with all the suggestions from above combined:
This is good:
.content {
width: 600px;
color: #fff;
float: left;
border: solid 1px #ccc;
}
.sidebar {
width: 360px;
float: left;
border: solid 1px #ccc;
}
This is not good:
.content{
width:600px;
color:#fff;
float:left;
border:solid 1px #ccc;
}
.sidebar{
width:360px;
float:left;
border:solid 1px #ccc;
}
Works with Single-Line CSS
You could also incorporate these spacing suggestions into single line CSS, to make it more readable. Look at this contrast, which incorporates all the examples above:
This is good:
.content { width: 600px; color: #fff; float: left; border: solid 1px #ccc; }
.sidebar { width: 360px; float: left; border: solid 1px #ccc; }
This is not good:
.content{width:600px;color:#fff;float:left;border:solid 1px #ccc;}
.sidebar{width:360px;float:left;border:solid 1px #ccc;}
Don’t Use Single-Line Blocks for Tutorials
I think all tutorials should use multi-line blocks (and the suggestions above) to be more readable, and to help keep the code highlighter from forcing a horizontal scrollbar. Again, I’m not saying that multi-line blocks are better. I know many people find single-line blocks more readable and easier to maintain, so that’s fine. But for articles and tutorials (even in print magazines) the best choice is multi-line.
What Do You Think?
I know, the argument can be made that removing some of the white space will make a CSS file smaller and faster to load. But at this point, I don’t think that’s an issue. If you use GZIP and other speed optimization techniques, then the few kilobytes you might save in your CSS files isn’t going to be a big deal.
So, what do you think? Do these suggestions make CSS more readable and scanner-friendly? At the very least, do they make CSS cleaner and more organized? Am I being too picky? And remember that this is not a debate between multi-line and single-line CSS, since these suggestions would apply to both methods.
I totally agree with you, i think is important to make readable code for multiple reasons, but the most important: the maintenance of the code in the future.
Surely this is an article whose main points could be applied to all languages?
At the end of the day, formatting style and convention is very subjective, but I can’t help but agree with you.
CSS Tidy might be worth noting too, as it deals with stuff like this: http://csstidy.sourceforge.net/
Thanks
Yeah, I think it’s important to keep css readable.
My style exactly looks like “right” variant of single-line css.
Additionally, I alphabetize my css. It’s something I do to make scanning lines of code easier.
e.g.: body { background:; border:; font:; margin:; padding:; text-align:; width:; }
Exactly. Having CSS sorted alphabetically is awesome to find the attributes we want to find, when searching for them. =)
I agree, but only for tutorials. For tutorials, everything should be done to enhance 95% of your readers’ ability to read the CSS (or any other language). For other code, it really depends.
For instance, I use single-line CSS with no spacing between one element and the next. Every line is a declaration, they’re already differentiated. When I used to do multi-line CSS, I definitely didn’t put a space between the previous curly brace and the next declaration. When scanning, that single curly brace on a line looks like a blank space, I don’t need any more. Actually, the only difference between his “really bad” single-line and my code is that I put a space after the semi-colons. This allows better groupings of individual elements (color:#FFF; looks more like one visual object than color: #FFF;). This helps me with my scanning, especially since Notepad++ has excellent highlighting for CSS.
My point isn’t that everyone should do anything one way, but you should assess the preferences of the team and try to find the best whitespace for the group with regard to the tools they use (for instance, if I was coding CSS in notepad or BBEdit, I’d probably have different whitespace preferences because of the different highlighting.)
Of course, on the tutorial side of things, it’s important to have coding that is easy to read. But not for live websites, especially if you or your client care about search engine rankings.
Something that hasn’t been touched on yet is page speed. Google is now taking page speed into consideration with their rankings and having a bunch of extra white space in your CSS creates a larger file which takes longer to load, thereby slowing your overall page speed.
I guess it would be good for someone to run some tests to see if the savings in CSS whitespace are actually worthwhile for Google rankings. Don’t get me wrong, I agree that page speed is now a factor in rankings, but how much of a factor will it be for an average size CSS file with a bunch of white space stripped out?
This is actually an interesting idea, and possibly something I might look into testing.
Hm… welll let’s see:
Depending on the collation the white space can be:
UTF-8: 20
UTF-16BE: 0020
Decimal:
Now imagine if you code in utf-8, this means that every “space” you insert additional 4 bytes.
Lets say your CSS file contains about 1000 lines of code (I want to mention that the new lines inserted are also 4 bytes), divided into blocks that occupy 9 lines of code with 1 new line between them.
So .. 100 blocks by 10 rows = 1000 lines of code. White spaces between curly brackets and properties makes 1 white space per line of code… 1000 white spaces by 4 bytes – you will save about 4KB.
It is not that much – so I guess it may not be that relevant.
Louis, this is questionable. 4KB for a site that have 1000 visits a day it’s ok. Doesn’t make difference.
But what about a site that has (more or less) 1 million of unique visits?
If you are interested in optimizing CSS for live websites, you should consider sending your CSS files gzipped. Check this website for more info:
http://www.samaxes.com/2008/04/htaccess-gzip-and-cache-your-site-for-faster-loading-and-bandwidth-saving/
It is my personal belief that you should always write your code with maintainability in mind. You never know when you need to look back at it. And in my case, you never know when a colleague needs to look back at it. If your production environment requires a less readable format, you may want to consider an automatic transformation to the desired format, like minifying it.
In my relatively short experience optimizing code by losing readability always comes back to hunt you.
I see this was posted about year ago, but I was wondering when you say each space and line break in code is 4 bytes. Is a tab 4 bytes as well? Thank you.
I like to Tab in my closing ‘Curly Braces’ so that the selectors are the only thing on the far left. It makes it even easier just to scan down and find the proper section of code.
Only thing I would add, and this really has nothing to do with “breathing room” but everything to do with readability, is /* comments */
I completely agree, especially when you work as a contractor in a corporate setting. I can’t tell you the number of times I’ve been brought in to work on a project, and wasted good time trying to figure out what elements related to each other (especially if they weren’t exactly named well. Seriously, what developer thought “new” was a good CSS class name? What the heck does it relate to?).
Even when I code a CSS file for myself, and know what everything relates to, it saves time.
In any case, blocking out all your different classes into appropriate sections, and commenting on what they’re for is extremely helpful.
I totally agree with this concept. At start of my HTML/CSS learning period, i did use multi line CSS, But now i m using single-line coding and still using spaces like you have said. I like it and i believe people found it more readable because in my co-workers students most of them like to view and write code in multi-line.
I agree 100%, but I would suggest having a human friendly file for reading and one which is actually used (without whitespace) for best performance. I know you don’t save much resources this way, but on the web miliseconds count :)
p.s.: I appreciate the much better design of the blog (although the right column seems a bit wide)
I think I create two stylesheets: One is the full, happy, readable version and one minified.
The biggest differences is I indent the closing curly-brace instead of adding a new line (which I think improves scanning) and when listing selectors after each comma I start a new line.
Once the site is fine and ready to go I duplicate my CSS then remove all unnecessary spaces and compress each declaration to one line, as well as removing all comments. It makes it hard to read but I save on file size and the full version sites in the same folder, just instead of styles.css it’s styles.min.css.
I don’t agree. When I create large stylesheets I try to keep the filesize small. So I get rid of the whitespace etc.
Use tools like CSSEdit to check the stylesheet of a site. CSSEdit has an option to re-indent (with spacing) so your ‘problem’ will be solved.
While it doesn’t get rid of all of the whitespace, I like to use Drupal’s built-in CSS and JS optimization features for this. I prefer to write my CSS in blocks with each attribute on its own line along with having certain specialized groups in their own file. What gets sent to the browser is one CSS file and one JS file.
This also helps to alleviate issues caused by IE’s bug that limits the maximum amount of CSS files it will process to 30 or so. It’s not uncommon on super-complex sites that use a plethora of modules to have a CSS file for each module included.
I think whitespace is important in all aspects of the design process, including the coding that sits behind the front-end.
I read an article somewhere that also suggests setting your CSS properties in alphabetical order, making it easier to scan/edit styles, (this is also how Firebug displays styles – in alphabetical order)
http://woorkup.com/2009/10/18/5-rules-to-write-more-readable-css-files/
Chris
I write CSS in alphabetical order, it’s a lot easier (to understand =)
I’m amazed at the attention to detail of all this white space with a lack of attention to detail in the formatting of this post.
The t and the r of #content and #sidebar got wrapped into the black color coding of the open curly bracket “{“.
I usually wouldn’t care so much but given the OCD displayed in this post, I would think you would notice the black r and t.
The “colors” in the code examples are beyond my control, save picking a new code highlighter. I’m using an older code highlighter, and I haven’t had time to research a more appropriate one.
The colors happen automatically, so sometimes they’re messed up. But CSS doesn’t depend on color, so I really don’t see that as an issue — especially in the context of this post.
Nonetheless, thanks for the reminder that I need to research a better code highlighter.
“But CSS doesn’t depend on color, so I really don’t see that as an issue — especially in the context of this post.”
+1
I hate it when people put spaces in the middle of a css declaration. Use it between the different attributes, not between the property and the value. Otherwise there’s no visual pairing of them. Either that or use double spaces between each property/value pair. Seriously, can you not see how much harder the first line here is to scan? And I mean scan. I don’t stop to _read_ the css until I get to the part I’m looking for. The whole point of using whitespace in coding is to quickly visually represent relationship and hierarchy because we process it faster if it’s visual. There’s no other reason to use it. If you put equal space between every little character and piece, you lose all visual distinction.
#content { width: 600px; color: #fff; float: left; border: solid 1px #ccc; }
#content{ width:600px; color:#fff; float:left; border:solid 1px #ccc; }
I disagree. But I do see your point.
I think when someone scans such a line, they’re not looking for a “pair”, they’re looking for the property (regardless of the value). They will see the value after they find the property — which is easier to find when it’s separated from the value. I personally don’t think “hierarchy” is important in that regard. But that’s just my view.
I agree mostly with you Crys.
I can’t stand when there’s a space after the colon, it makes it so much harder to associate values and properties when they’re all 1 space apart, especially in the first example you gave.
Everything else in the post I tend to agree with, usually though I put the { and } on new lines.
I also tend to use 3 or 4 different methods to organize my CSS files as I see fit for each selector and how many different attributes it has, what section it’s a part of – all globals (floatLeft/Right, clear, redTxt, redBg…) tend to have only 1 attribute, so that whole thing goes on one single line, and all the others follow that one line approach.
Every time the user’s pc has to work a little bit harder to process a page, it uses more energy. I know the extra amount is hardly noticeable, but times that by millions of sites and billions of users and it soon adds up. The only time you need lots of neat, well spaced code is in tutorials. any other time, your css should be 1 line long with no white space.
Well I agree, but isn’t it same having a space or new line? will have to create HUGE CSS file to test it out. In my opinion it is better to delete all unnecessary code than white spaces or new lines. You can see some sites with single line but their CSS file has bunch of unnecessary code.
I’ve used all of these practices since the start and I’ve recently been interning at a company that uses incredibly messy css and html. Most of their css is inline as well, and sometimes I have to rearrange the code so that it’s readable enough for me to even start working on a project.
Hi I am new to html and css. I wonder why did the enlarge the width of the css code. There must be a reason.
Whilst I agree that in most of the cases above the “this is good” part is slightly more readable and clean than the other, the difference is really tiny. In fact, I find all code examples in this tutorial to be perfectly readable. Ideally you let an IDE take care of this, it would be a real waste of time code reviewing such marginal things.
Don’t get me wrong, I do value code readability, it’s just that all the examples above are perfectly readable to me.
The only rule I definitely disagree with is the space behind the colon. It goes against my intuition and I cannot recall this being a common best practice at all. I think you just made it up, like you said.
Although I agree with the empty line between two blocks, I think you’re just a little bit too picky on the other suggestions (the whitespace before the bracket e.g.).
I think people all have their own ideas of what they find clean looking, organized code. The most important thing is that the people who have to use the css file think it’s looking good, and have no problems spitting trough it.
For open source thingys, tutorials, templates or whatever a lot of people get their eyes on I agree there should be some kind of standards, like the suggestions you listed here. Thanks.
I agree wholeheartedly. On the multi-line vs. single-line coding, I would say single-line for production level work and multi-line for tutorials for readability. Of course, just adding comments helps a bunch as well.
I agree 100% with both points here. My source codes include fully formatted css code, with all the spaces, etc. When I publish my site, I have a python tool that removes all that “human-readable” stuff and compresses it for loading. It’s just an extra step in my fabric file. So, best of both worlds. I can override the compression when publishing to a staging site, so debugging the css is easier too.
And definitely alphabetize the individual entries.
Each to their own I think. I tend to write it the same as the “good” example above, it is easier for ME to scan through. Some people find it easier to read single lines of declarations though.
It’s all an exaggeration that’s not good, there should be a measure of all things … ;)
Interesting read and comments. I personally use many of the “good” methods described, but that is for mostly a personal preference. To me it makes it a lot easier to scan over and see what is what. I like the idea of once a project is ready to go live creating a condensed version for actual use. I think I may start incorporating that. As for alphabetical, I like to write most of my css first so I start from the top down on a site and list the selectors in the order they are on the page with comments identifying where major grouping structures begin and end. I have found these techniques work well in my company for some of the new designers to read and use when working on the site.
I use all of these styles, although I do occasionally forget to put a space after the colon. I also put all my colour hex codes in all capitals, as I believe this makes it look more readable and cleaner.
I personally use single line coding, I did use multi-line when I started but I have eventually moved on to single line as it uses less whitespace which makes the file size smaller (even if only a little) and its just what I have become used to :)
Single line coding is faster and no doubt smaller file size, but when it comes to maintaining, it would be different.
Also, single line coding is only good for single user.
It will be hell if you pass your code to the next guy to maintain it.
I think this is a good article, and covers some good points about CSS layout for readability. I admit to using some 1 liner css declarations but sometimes CSS doesn’t warrant being on multiple lines (eg when styling font’s).
I think your code should be easy to read, well commented like /*This fixes an ie6 layout bug*/ so people know why something was used in the CSS!
When uploading to the web server (live version) I think using a CSS compression service is better to allow the code to run quicker! :D
I don’t disagree with you, but I just have an easier time parsing more lines at once using single line CSS in this format:
.selector {margin:10px; padding:15px; float:left;}
The spacing between the semicolon and the next style and ONLY there makes it easier for me to identify multiple styles more quickly.
I’m definitely not saying you’re wrong or that I’m in the majority; it’s just my preference.
I am annoyed by your CSS property arrangement.
It could be better if you Alphabetically arrange Property.
This makes CSS more readable (as what this article is all about).
Writing and modifying also will be faster.
I’ve heard many people say this (as they have also in these comments), but I don’t see it as a huge advantage. First of all, it takes a lot of time to arrange properties that way. Second, I think it’s just as logical to group things in order of related properties, with more generic ones like “display” and “float” near the top.
If it works for you, then that’s great. But I don’t have the desire to rearrange every block of CSS I write, to ensure it’s alphabetical.
It takes some practice to arrange it but its all for the greater good, either logical or alphabetical. Neither will have huge advantages like what you said.
Nonetheless, great article. Hope can hear more from you! Cheers.
I’ve always preferred to arrange by related groups (I typically order things how the property appears, like Header, then Nav, then Content, etc, with the generic things on top). Having all the properties relating to, say, the Footer in one group, as opposed to scattered throughout the stylesheet, is much easier for me to find.
I think you use too many white spaces and my solution would be the best:
/*HEADER*/
#logo{ }
#nav{ }
/*CONTENT*/
#content{ width:600px; color:#fff; float:left; border:solid 1px #ccc; }
#sidebar{ width:360px; float:left; border:solid 1px #ccc; }
/*FOOTER*/
During the design steps itself it is very necessary to make it all readable,
once in production the speed and agility of the css-file (thus the length) should prevail, good commenting can help out when something needs to be re-vised on a later date, so, readability AND good commenting is key here…
If you are new to CSS, ignore this article and do whatever works for you. This is nonsense.
Yes please give CSS some room to breathe. I see people disagreeing with the points about having a space before the curly brace and after the semi colon but I agree with Louis. These are practices that are the same in other programming languages. I don’t think I’ve ever seen code where there was no space between “if” and the curly brace.
A space after a special character such as the semi colon is also required in natural language writing.
Haha! This is exactly how I write CSS. I’m glad to see it’s good practice.
Personally, I like each selector on a single line so that I can quickly ready left to right and see groupings of css blocks and commented as to what they are more clearly. However I myself like to compress all of my code for prime time while still remaining an uncompressed version locally in my archives.
Absolutely, 100%, yes.
This is exactly how I like to format my CSS.
To those worrying about whitespace, I actually maintain two copies of the CSS – one like this for dev, and one completely minified for production. It’s easy enough to switch based on IP address too, so I don’t have to keep adjusting my html to decide which css file to use during dev and updates.
Yay it’s not just me! Whenever I inherit someone’s code I find myself reformatting the CSS exactly as in these “good” examples. It drives me mad otherwise.
I do agree mostly. I don’t bother with the line in between separate blocks, but I do actually indent my CSS in a heirarchical way, which makes it much easier to read as you know where to look for childs-styles over main styles.
Because I have a minification script running I don’t need to worry about whitespace, which makes it all the better for performance on the front end and readability my end! :-)
No. As little white space as possible! This is not a visible file and nobody other than the developer / designer will ever see it. I agree that it needs to follow a format and be legible but, it needs to load quickly so keep it small and beautiful. </end>
Agreed. Which is why its important to compress and keep a local development version.
I really don’t see the point of this. As someone who regularly has to churn out large amounts of code relatively quickly, worrying too much about little things like a whitespace between the selector and the opening brace just seems silly. Just so long as you’re using a good enough IDE with proper syntax highlighting and color coding, then all of this is redundant, and just wastes time and data size. CSS can still be perfectly readable without any of this stuff (though one thing I do stand by is a space after semicolons in single-line CSS), and just prettifying your code like this seems like a whole lot of effort when nobody’s going to look at it but yourself. In the fight between spending time making sure the code’s laid out perfectly and concentrating on enhancing the functionality, pretty code loses every time I’m afraid. Readable yes; pretty, nah.
I’m slightly confused if this is supposed to be serious or not. There isn’t any ‘good’ or ‘not good’, write how you want, and then minify it. It’s kind of silly talking about the readability of css, since I believe most IDEs’ have a reformatting option to put it into block form with all your spaces in it if that is how you want to read it.
I also indent the closing brace so that it creates a nice eye trail down your declaration blocks and down the brace. When the brace is flush left it is jarring on the eye.
On a production site it’s usually wise to push your CSS through some minification, caching and delivered to the browser zipped. Here’s a nice and easy script to help you do so:
http://rakaz.nl/code/combine
I use single line declarations but follow most of the other “rules”. I use single line because I work on a 27″ monitor and it’s nice to see all your code at once instead of having to scroll for miles and miles. I actually find it much easier to read than multi-line. I think the most important “rule” is the space after the colon. Not only does it make things much more readable but on a mac at least… with my editor of choice… the space allows me to double-click to select just the value.
For single line blocks, use spaces between property/value pairs but don’t use a space between property and value. That way property/value pairs are nicely separated, making them easier to scan. The example you’re giving here looks like a random list of words rather than clean, readable css.
As for multiline css, no comment :)
if you minify the css, isn’t it just all going to run together anyway?
That is exactly how I write my CSS. I think it’s important to note though, that this is what the “development” copy of the CSS file should look like. In the interest of speeding things up, you should also have a “production” copy that is minimized and has as many of the development files as possible merged into one.
I guess everybody has his own ways of putting everything together…I tend to put styles with 3 or less short properties on 1 line, I group styles related to the same element directly below eachother, without space between the blocks, and so on. I’m so used to it that it’s alot more readable for me than the ‘standard’, so.. :)
I agree with you from a tutorial side, but with regards to production websites, I use single line.
I write my CSS similar to yours however I put the first item right after the first curly brace and put the last curly brace right after the last item so they are on the same line instead of putting each curly brace on it’s own line. Then I add a blank line before the next notation for visual benefit.
I totally agree with your above mentioned points. We should make the code as much readable as we can so that we can easily modify it in the future.
If you know how to read, all are the same :)
If you have a problem to be solved, the search function already can be found …
This is a good point, because in most cases, the CSS formatting won’t matter too much since you’ll be using the “find” functionality of your editor to locate stuff.
However, there are times when you are working on a specific area of your code, and you need to scan it to locate something, then add/remove stuff. That’s when I feel the readability is important.
To me,CSS that’s not correctly spaced is like this.A sentence that doesn’t have space after punctuation,like commas.And periods.See what I mean?
I am failing to understand the logic of those that are saying something along the lines of “what is the point of this if you are going to minify the CSS for production any way?”. How about the readability of the CSS amongst a team of designers while the code is being written? Surely the code will need to be maintained for edits and additions too, so keeping a suitably readable CSS document that pertains to a set of rules amongst the team is strongly advised.
You’re exactly right. A guy I work with does all the things that the author of this article says not to, and it is very difficult to edit his code. But it’s his code, so that’s how he continues to write.
I almost totally disagree.
Having worked on some really big projects like Tesco.com, National-Lottery.co.uk and Boots.com with many people who collaborated with me on the code, scrolling up and down in CSS was the most annoying thing.
Separating lines of CSS code does almost nothing in order to increase readability. In a file with 7000 lines of CSS code (written in one line for each declaration), scrolling is the biggest problem and a great time waster.
Narrowing down the amount of scrolling I have to do on a CSS file is incredibly important. Also, we tend to use replace all for large search and replaces, while using ‘find’ facility is also common to find relevant declarations.
I think the key thing is to group declarations on the basis of components, sections or pages on the site. This is by far the best way to organise CSS and make the code more usable.
Thanks.
If you have 7000 lines of CSS code, then you’re doing something wrong: your code has a low reuse rate. CSS has a tendency to get bloated in this way; I’d recommend checking out Nicole Sullivan’s “OOCSS” approach. Her Velocity 2010 presentation was particularly good: http://www.youtube.com/watch?v=j6sAm7CLoCQ&feature=player_embedded
It’s not just you. Almost everyone has been writing CSS wrong, including me. ;)
You can also organise your CSS into multiple files, logically separated into different areas of the design (e.g. reset, grids, page template, typography, media blocks…). This helps you find the CSS you’re looking for without excessive scrolling. For performance, these files then get concatenated together as part of your build process.
I agree with Jason Grant. As a developer who routinely works on large projects, having each selector on a new line is a recipe for certain frustration. The amount of scrolling is absolutely unnecessary, and when searching for the rule on a particular element, downright annoying. After gaining familiarity with single line declarations, they are no more difficult to read, and save valuable real estate. Commenting and labeling your code is far more important to readability and organization than spacing IMHO.
I agree with the suggestions, However, space after the colon is somewhat dicey. It “breaks” the readability of the code for me as the space denotes that the value is different from the property.
Another area to concentrate for readability of the CSS code is the naming convention for the different styles. If the same convention is used then it is easy for another coder to understand the code. The logic of the naming convention can be added to the comments at the start of the CSS file.
Any other suggestions for naming convention.
I prefer doing it the firebug way,
sorted alphabetical, reduced.. surely correct.
Wrong track?
I disagree with your single-line format.
Personally when writing single-line CSS I do not put a space after my colon. This makes it easier to spot the property I’m looking for, instead of searching through seemingly indistinguishable properties and values. Even more so since the terminating colons and semi-colons also look identical.
This is better:
JP,
I deleted the other messages. Is the above how you wanted it formatted?
You do make a very good point for single line BTW, thanks.
I agree with you, I think its better if you write your CSS as per the logical blocks on web page, and order your styles alphabetically. Moreover, at the time of deployment, you can always compress your CSS. And why don’t use utility like CSSEdit, it has features to add proper indent so in case you don’t have un-compressed copy, then you can format CSS using CSSEdit.
Thanks Louis, I’m trying to improve my CSS skills and your posts help me alot!
Hi,
yeah thisis great post evea …. am also trying to improve my css still and this post help me alots .. am also looking css fixing in IE. keep posting help other like me.
I agree completely! When I get lazy, just crewing around trying some things out, if I end up using it, I just hate myself later when I’m going through item by item trying to visually lean it up.
I think the article would have been more useful if it had compared CSS styling to code styling – e.g. to indent or not-indent. THAT is what makes CSS readable, just as it does with markup, c# or javascript. I see absolutely no reason whatsoever for separation of CSS blocks with empty unless you’re grouping classes together (e.g. everything to do with formatting the header) – in which case it start with an explanatory comment.
Consistency is far more important.
Every line space is a bad idea!!!
We use this style only. So much easier to read, if you ask me.
#content
{
width: 600px;
color: #fff;
float: left;
border: solid 1px #ccc;
}
#sidebar
{
width: 360px;
float: left;
border: solid 1px #ccc;
}