This post will focus on the different ways to format CSS, which differs from the different ways to organize CSS. Definitely related concepts, but I think organization has more to do with how things are grouped and ordered while formatting has to do with spacing and indenting.
Formatting has nothing whatsoever to do with how the CSS functions. These are merely aesthetic choices by the coder. But that’s not to say formatting isn’t important. That would be like saying the choice of canvas isn’t important to a painter. It affects how it feels to write CSS, how easy it is to read, how easy it is to navigate, and how easy it is to revisit and reacquaint yourself with previously written CSS.
The reason there are so many choices with CSS formatting is that there are no hard syntax rules when it comes to spacing and line-breaks. For example:
div { width: 50px }
is the same as:
div{width:50px}
is the same as:
div
{
width: 50px
}
Multi-line Format
.navigation_rss_icon {
position: absolute;
left: 940px;
bottom: 0px;
}
#navigation_rss {
position: absolute;
left: 720px;
font-family: Verdana, Arial, Helvetica, sans-serif;
text-transform: uppercase;
color: #897567;
line-height: 2.5em;
}
#navigation_rss li {
display: inline;
}
#navigation_rss li a:link, #navigation_rss li a:visited {
color: #fffffe;
text-decoration: none;
padding: 0px 2px;
letter-spacing: -0.05em;
}
#navigation_rss li a:hover {
color: #eed2a1;
text-decoration: none;
}
I’d wager to say this is the most common. It is the easiest to read when it comes to short snippets, which is why written tutorials most often use this format. The example above doesn’t have a blank line between the closing brace and next selector, but that is fairly common as well.
Multi-line Format with Indenting
.navigation_rss_icon {
position: absolute;
left: 940px;
bottom: 0px;
}
#navigation_rss {
position: absolute;
left: 720px;
font-family: Verdana, Arial, Helvetica, sans-serif;
text-transform: uppercase;
color: #897567;
line-height: 2.5em;
}
#navigation_rss li {
display: inline;
}
#navigation_rss li a:link, #navigation_rss li a:visited {
color: #fffffe;
text-decoration: none;
padding: 0px 2px;
letter-spacing: -0.05em;
}
#navigation_rss li a:hover {
color: #eed2a1;
text-decoration: none;
}
A block that is indented indicates the selector is a more specific selector than the parent above it that and targets what will be child elements of that above selector.
Single-line Format
div.wrapper { margin:0 auto; padding:200px 0 0 0; width:960px; z-index:2 }
ul.nav { position:absolute; top:0; left:430px; padding:120px 0 0 0 }
ul.nav li { display:inline; margin:0 10px 0 0 }
div.column { float:left; margin:0 70px 0 0; padding:0 0 0 70px; width:340px }
div.post_wrapper { background:url(http://cdn.images.elliotjaystocks.com/presentation/hr_long.png) bottom center no-repeat; margin:0 0 40px 0; padding:0 0 40px 0 }
div.wrapper img, div.wrapper a img, div.article_illustration_mini { background:#d3d4cb; padding:10px; border:1px solid #999 }
div.wrapper a:hover img { background:#fff }
This is probably the most space and size efficient, short of being completely compressed to remove all spaces and line breaks. This technique would require the least vertical and horizontal scrolling as you write and edit CSS, but at the potential cost of looking messy and somewhat difficult to browse and find things you are looking for.
Single-line Format with Tabbing
h1, h2, h3 { font: 24px Helvetica, Sans-Serif; margin: 0 0 10px 0; }
h2 a, h2 a:visited { color: #2e2e2e; }
h2 a:hover { color: #fe4902; border-bottom: 1px dotted #2e2e2e; }
p, li, dd { font: 13px/18px "Lucida Grande", Arial, Helvetica, Sans-Serif; margin: 0 0 15px 0; color: #5e5d5d; }
td, th { font: 13px/18px "Lucida Grande", Arial, Helvetica, Sans-Serif; text-align: left; }
Single-line Format with Indenting
#content-area ol { margin: 15px 0 0 25px; list-style: decimal; }
#content-area ol ol { list-style: lower-alpha; }
#content-area ul { margin: 0 0 0 5px; list-style: none; }
#content-area ul li { padding: 0 0 0 20px; background: url(/images/bullet.png) 0 3px no-repeat; }
#content-area ul ul { margin: 15px 0 0 25px; list-style: disc; }
#content-area ul ul li { background: none; padding: 0; }
A selector that in indented indicates that the selector targets something that is a child of the selector above it.
Mostly Single-line Format
I prefer the single-line format, but I use Soft-Wrap in my text editor, so that long lines don’t go on forever, they wrap at the window edge. So for really long lines with lots of selectors, I put a hard-return and tab over the new line of attributes.
h1, h2, h3 { font: 24px Helvetica, Sans-Serif; margin: 0 0 10px 0; }
h1 { font-size: 36px; }
h2 { font-size: 30px; }
h2 a, h2 a:visited { color: #2e2e2e; }
h2 a:hover { color: #fe4902; border-bottom: 1px dotted #2e2e2e; }
p, li, dd { font: 13px/18px "Lucida Grande", Arial, Helvetica, Sans-Serif;
margin: 0 0 15px 0; color: #5e5d5d; }
td, th { font: 13px/18px "Lucida Grande", Arial, Helvetica, Sans-Serif;
text-align: left; }
Variations
The single line format could be taken further by moving the opening brace onto it’s own line, which is something I see in PHP quite a bit:
div
{
padding: 10px;
}
In the multi-lined format with tabbing, I have seen the opening brace used as kind of separator wall:
#content-area ol { margin: 15px 0 0 25px; list-style: decimal; }
#content-area ol ol { list-style: lower-alpha; }
#content-area ul { margin: 0 0 0 5px; list-style: none; }
#content-area ul li { padding: 0 0 0 20px; background: url(/images/bullet.png) 0 3px no-repeat; }
#content-area ul ul { margin: 15px 0 0 25px; list-style: disc; }
#content-area ul ul li { background: none; padding: 0; }
Combo
A combination of single-line and multi-line would be only grouping related attributes onto a single line:
.navigation_rss_icon {
position: absolute;
top: 10px; left: 10px; bottom: 10px; right: 10px;
font-size: 12px; font-weight: bold;
}
Readability vs. Scrolling
Your choice of formatting boils down to readability. You need to be able to navigate your CSS quickly and find what you are looking for and make changes quickly. If you find the single-line format difficult because it is hard for your eyes to find the attribute you are looking for, then you should probably avoid it.
Personally I find the multi-line format easy to read, but it increases the length (like actual number of lines) by 5-8x. This actually makes the whole document less readable for me, because of all the vertical scrolling. If you have a somewhat narrow monitor, the single line format might cause a good bit of horizontal scrolling which is sometimes even worse.
The perfect format for you is one that maximizes readability while minimizing scrolling. Plus, in a more abstract sense, it just needs to feel right.
I’ve never seen anyone wasting extra lines in CSS by placing each opening brace (“{“) on its own line. By the way, it’s = it is.
This is the default format in Visual Studio, and is used by many developers.
I don’t particularly like this format. However, it is used.
This the the formatting style I prefer and I’ve never worked with Visual Studio. I use BBEdit’s jump to declaration tool a lot, so most scrolling is eliminated from the start (this actually works for most languages in BBEdit, it’s a great tool).
In the end, it doesn’t really matter. It’s just about what you (and your team) prefer.
I like this format also. Just seems easier for me to read. I don’t like putting all the like attributes on the same line either. Also, I try to put the style attributes in a particular order every time. ‘Float’ and ‘Display’ go before ‘Height’ and ‘Width’. Then comes ‘padding’ or ‘margin’. Etc. I’m not too anal about it but it helps me when I’m debugging.
I’ve = I have.
Actually, it’s == it is.
It seems like it would make sense for editing, for example if you were going to add another line
I prefer the multi-line format but I think you should have mentioned css-comments?
Also, some editors use CSS groups (can someone write a Coda plugin PLEASE?), for example CSSEdit or I think Textmate do.
You can write stuff like
…and then you can jump to groups and open/close them in your code navigator. Pretty awesome feature if you ask me.
Intending sub-classes is a new idea for me though, thanks!
Awesome. Thank you Tom, I tried this out in Espresso and it works great.
It works perfect! You should try it in CSSEdit as well.
I’ve recently become a fan of the Combo format. It creates a nice compromise between the readability of multi-line format and the compact single-line style.
I’ll put all box model rules on the first line with width and height, background gets it’s own line, positioning on another, and text-formatting gets the last line. This way has led to my wife understanding my code easier – both as a standard format for reading, and as a clue to the way I approach CSS. She usually just does graphics and I code – but lately this CSS format has let her do more changes without me there.
I use the multi-line format, but I put the second brace at the end of the last property, like this:
That’s because I’ve developed a habit (for no particular reason) to declare the longest properties last…
Great post, thank you!
Did this too some time ago, but when you’re editing something at the end of a multiline-block then the end-brace is in the way, you have to click in between and sometimes you delete it…so I decided to break it a line down and take it back to the css-selector, works best for me…
#navigation_rss {
position: absolute;
left: 720px;
font-family: Verdana, Arial, Helvetica, sans-serif;
text-transform: uppercase;
color: #897567;
line-height: 2.5em;
}
I use the Mostly Single-line format.
In a site I’m building for a client at the moment, there are close to 343 lines of CSS, in the single-line format, that would be extended to well over 1500 if I used the multi-line format. Thar’s just taking the piss!
I just think the multi-line format is a waste of valuable space.
i do it this way:
and so on. i see everything i need and i see the hierarchy, so i can quickly jump to what i’m looking for.
This is exactly the way that I write my CSS too. I find it gives a good balance of readability and scrolling.
I think this works for me, because when I’m looking through my CSS, I’m normally looking for the selectors, not particularly the properties/values.
The same over here.
I also group Sections ( e.g. header, Content, Sidebar ) with Comments ( /* @group Header*/ … /* @end */ )
Mapping the Structure of the Markup, while i am in the development process is essential for me.
I also do like that, like a tree!
During development time anyone can format how he likes but everyone should remove any formating/whitespace when code goes to production.
I think you meant to add, “unless anyone is going to need to maintain it” q;
Even then, there are enough tools that reformat it when you need to apply changes, or what we do: Our deployment tool (or webserver) creates the minified css that is send to the browser. In development anyone uses the formatted version.
Nice post. I was trying to find auto formatting tool yesterday, and by accident I find how Aptana Studio (ctrl-shft-f) autoformat CSS. It is very cool Multi-line method. Sample code:
Very cool? It looks awful, as it there were only one class. If I worked in a team with somebody producing that, I would ask him/her to be fired because productivity goes down trying to read such a code.
You’d ask for them to be fired? that’s a little extreme. Wouldn’t a quiet word in their ear be a better approach ;)
I still try to find the “very cool” bit up there. hmmmm
The way I use css is similar to the “Multi-line Format with Indenting”.
Oh and what the post also does not cover: (how) do you sort the declarations?
After some time of experimenting I prefer sorting them simply alphabetically, so they’re position always in the same order.
My CSS looks like this
Of Course better formated with tabs.
I prefer multi-line because it is easier to keep the overview if there is a bug in a line.
If my dev.toolbar marks an error in line x and the code is in single line i have to search longer then multi-line-code
I completely agree with you.
That’s also how i format my css.
Multi-line formatting + Comments = Quick debugging
I think that debugging really requires more than the single-line formatting. That said, there are often also specific notifications like,
“Error on style.css line 21, found color #FFFF, expected color” or whatever, which makes it pretty quick to zero in on which property was actually declared incorrectly.
I think after reading this article that I’m going to adopt my style to a hybrid one, including indentation for child elements. Makes a lot of sense to me to immediately spot the children.
I like the idea of keeping properties with similar roles (positioning, appearance, etc) together, as it allows you to take some advantage of vertical-scrolling optimization while at the same time having meaningful debugging information.
some would even occurred to me, but thanks for the interesting ideas, most of it is applicable only in the development …
I prefer single line indented, like that:
I’m a single line man myself.
I hate scrolling down, what can seem like forever with multi-line files.
And being an espresso user, I use the addition of groups like tom mentioned.
I am on a single line with this one as well. Much more compact and if you apply logic of blocks, it’s not hard to read at all. Just takes a bit to get used, but once you feel comfy with it, it’s all better.
I think for production it’s better to minify CSS. And for development you can use formatting you like. I prefer multi-line with indent. Like this:
I like the way you format the css that is shown at the entry of your screencasts, e.g.
But I doubt that someone would really put as much effort in the formatting of css rather than formatting the website.
I also appreciate that Textmate shows you all used ids, classes and tags used in the css to easily select them. Together with a little formatting work on your style sheet should save much time.
Bego
this is what I do. I tend to be scanning for a specific selector when looking at a CSS file. This style really makes the selector stick out and the rest be fairly compact. Once you’ve found the rule you are looking for it’s easy enough to distinguish the specific attributes.
Everybody does what they’re comfortable with. What works for them, may not work for others. Where it may get challenging is when you’re working with a team of people writing the CSS. That’s where it’s important for the team to discuss a format that’s easily manageable by all. Nothing is worse than reading through someone else’s stylesheet when you’re not used to their formatting style.
I know this is off-topic.. but I long for the day when this is possible:
Is something like this in CSS3?
No, this is not in CSS3 but it’s available in Less CSS
Wow, Less CSS looks interesting and potentially really useful! Am I right that it’s only for Ruby?
Same sort of thing – but with PHP
http://wiki.github.com/anthonyshort/csscaffold
It can do a lot more too :)
I put my selectors on new lines as well, since I often try to group selectors together for easier editing. A simple example:
@Jacob Rask full ack
@admin nice post!
Furthermore i can recoomend to seprarate Type, ID and class selectors.
Then sorting all selectors alphabetically of course ;)
You’ll never read and find text so quick when you have a >1000 line file.
i use single line with tabbing. I think it create, not only a very elegant look, but a great balance between compression and readability.
also “tabbing” screws up formatting in different programs, so I use the space bar to “tab” my CSS
Tim Wright: Compression should be done by minifiying your code before the site going live, instead. If you consider it an issue at all.
minifying code without gzip compression makes it unreadable – and fairly useless. That’s why I said it’s a balance between compression and readability
its single line for me. if you’ve never tried any other format, I recommend you try each one once. I thought that single line was going to be a nightmare at first, but then I found it was even easier for me to find and read code!
I’m an old-school, multi-line formatting myself.
I did try both the single line and tabbed single line, but found myself spending too much time hitting the tab key just to get everything in line.
– Martin
I used to do single line but when I had to edit something I didn’t really like.
I tried multi-line indenting children once, didn’t like that, turned into a nightmare with so many children.
Visual Studio does this nice job of setting the braces up like so:
div#page
{
margin:0 auto;
width:952px;
}
Then I just do everything alphabetical and just group selectors together, usually with some giant comment block to know what the group is for.
Ah, that should be 1 tab on everything after the first brace. Does this work…
div#page
{
margin:0 auto;
width:952px;
}
I prefer “Multi-line Format with Indenting” in many files; and convert these to a compressed single fle for publication; I review the compiled file for repetition and unused selectors which I change in the single file then if the edit does not cause issues I make the change in the more readable file. Having recently found compass & Sass (as in Hampton Catlins HAML & Sass) this can be taken a level further.
I use a combination of single-line format and multi-line format. My editor (Textmate) shows me where the column 80 is. If all the rules can fit within it, then the single-line format is used.
Otherwise, I use the multi-line format. Why column 80 you wonder? It allows you to see all the rules in a selector without scrolling horizontally
I mix and match – multi-line normally, but single-line when I have a group of similar selectors, like this:
Doing it that way makes it easier to see the differences between #box1, #box2, and #box3 (the width).
I’d do
and so forth..
No need for search-and-replace for colours then, for instance.
Great post Chris, You should create a poll for this topic. I would be curious to see the results.
I am a newbie here but I find it a lot more organized when I used a combination of the multi-line format along with commenting out each section. That way I can easily scroll to the portion I am working on and make my necessary changes. I guess I am extremely typical. Oh well.
I’m a fan of multi-line formatting myself. Although the final output is longer, I find it so much easier to read and find what I’m looking for. I find the single line variants to be too condensed. I’d almost say I feel claustrophobic looking at that style of code, LOL. I’m all about clean design, and multi-line formatting does that for me perfectly. Especially when it’s organized into groups with comments, etc.
Using a multi-line format allows one to gain a tremendous benefit from version-control software like Subversion.
I sort my declarations alphabetically. This helps prevent duplicated decalration.
I’m a mulit-line with brackets on own line kinda guy…
just what seems natural to me as that’s how I write my .NET code.
I’ve always used multi-line format, pretty much as you post it but with an extra line break after closing braces. On a site I made very recently I decided to try multi-line with indenting and I absolutely love it. I find it really helps when navigating the file and has reduced the amount I use the find function in noptepad++ (my editor of choice).
I like both single line and multi-line. I use single line most of the time to save space but I also like the look of multi-line. I don’t really like the look of the multi-line, indented style. That seems too jumbled to me. It really comes down to personal preference, but a standard on this would be nice to have. Especially when you have to make changes to someone else code and they favored a different style than you prefer. Not a big deal but it would be nice.
I use the Mostly Single-line format. I find it easier to find a specific class/id that way. I then also group them by way of comments as to how they appear vertically on the page, i.e
I use multi-line, with indenting.
Voting for this method, but without empty line between blocks:
#header {
... .......
}
#header .logo {
...... ....
}
#header .banner {
.... ...... ......
}
Definitely multi-line for me, just seems to come naturally. Also list properties in alphabetical order – it the organiser in me! Do tend to include more spaces while I’m working on the code, which I get rid of once finished. Single line format appears way to confusing for my liking. Can imagine it being hard to locate & change properties & values with any ease.
I use a few combos of the above – but if using multi-line I think it’s good practise to keep it alphabetised – that way it’s easier to find what you’re looking for later on.
putting the code on single line will definitely make the file lighter if you have lots of classes and ids defined. this should always be practiced.
I like multi-line formatting, even though the code is longer i think its more readable.
I don’t know how anyone uses any kind of single-line formatting. I’ve always used multi-line, simply for the readability.
I use single-line with tabbing and indenting. I like to keep my CSS declarations on one line; for me it’s easier to read than seeing everything broken up line-by-line.
Tabbing just helps me better determine what that CSS declaration is effecting (ie. is it working on ‘container’ or perhaps something WITHIN ‘container’)
In addition, I try to lump things together – like if an object is floated I tend to always open with float: left; display: inline; width: AApx; height: YYpx; margin: BB; padding: ZZ
not sure why but none of the indents show in IE7 on this page. really hard to see the example indents on ie7 when they are not showing.. it works in FF3.5 ok.
although if I copy the pre/code input into a separate html file, it will display as indented correctly.
what’s going on?
Al
I use multi-line… just easier to read and I don’t care about scrolling.
When you find something in firebug it will tell you which line its on… and its easier if you dont have a huge string to look through.
CSSEdit formats code pretty nicely.
I use single line with indenting to identify parent child relationships. It has always been the easiest to read making it easier to find and edit when necessary. I enjoyed reading about other ways to format.
I’ve been wrestling with this subject for a while on my blog too:
http://www.nickyeoman.com/blog/css?layout=default
I’d love your guys’ input.
Cheers Ben
I like this wee post…. I have just witneseed something I have not seen, indenting child elemnets, that is something I have never even thought of, but such a cool idea to keep your code well organised.
I have seen the multitude of ways code, but I have to say when I first learned to code it was java, and I was taught to write it like
so I kept my CSS to look similar with the curly braces on their own line, like my php does, but with multiline, it is easier to read and find problems, like a : instead of a ;
don’t these also affect page load times? I’ve heard of people even minimizing their css to help overall site performance.
I use the “Mostly Single-line Format”, because CSS has a simple syntax and it saves space. For programming (PHP, Python etc.) I use the Allman style.
After much, much deliberation and code comparison, I’ve figured out that I use the following CSS formatting style:
Indented, Mutli-line, Alphatbetically Grouped Format with some Tabbing and Color-coding for readability.
No, you can’t view a sample because you’ll all point and laugh! ;-) By the way, I always thought of my “eccentric” coding as a means of job security (since I was the only one who could read it).
This is a very unique but informative post on something everyone can relate to.
I use single line, but I agree that you should’ve noted something about comments. I always separate my css with comments at the top of everything, the more indented the more general that group of css is.
For example:
/* Template Styles */
/* Header */
#header { … }
#logo { … }
/* Content */
#content { .. }
I am thinking about indending similar id’s/classes but I’m fine with readability and everything for now. My CSS tends to be huge, so not having to worry about compressing it later is a relief.
My indenting didn’t seem to show but I think you get the idea.
/* Template Styles */ would be somewhere in the center while /* Header */ would skip 2 spaces or so.
Personally for me when I code CSS I use the multi-line format for everything unless the snippet I am writing only has one… Umm… Example: * {outline: 0;}. One of those. Other than that I will use the multi-line format.
I actually use the multiline format, but just before I’m deploying I use the YUI Compressor to compress it to the unreadable one-line format.
I always keep the original in a seperate file, and if (god forbid) I lose the original, I use a CSS decompressor, to make it readable again (in a multiline format)
If anybody’s curious:
YUI compressor:
http://developer.yahoo.com/yui/compressor/
CSS (de)compressor:
http://www.automotivecenter.nl/diversen/utility/csscompressor/
I usually go with the single line one, but instead of indenting I go with empty-line grouping
SASS SASS SASS SASS. Oh, did I mention SASS.
http://sass-lang.com/
Having recently taken a position with a crack development team I have been introduced to a few technologies that have changed my life. One of those is SASS. CSS formatting conversation pretty much end there.
If you are in an environment where you can embrace this technology, I strongly suggest you do so.
-David :)
Multi-line format is clear and easy to reading. I use this format the most.
Hey everyone! I like to use one-liners as long as they are not too long. Otherwise I group related rules on a single line
Great post and discussion as usual, Chris!
I’ve always hated that standard practice of putting the first brace on the first line.
I used to do single-line, but it was just too messy. I found that anything besides the selector, in the first tab-column-thing, distracted me, so I indent the braces and further indent the CSS rules.
I use single line for when I only have 3 attributes, more than that I change to multiline. Also try to list attributes alphabetically.
eg.
you also have Object oriented CSS, haven’t tried it yet but sounds promisisng
http://wiki.github.com/stubbornella/oocss
I write pretty bad CSS so I just use an organizer (styleneat.com) frequently. Saves time doing it all manually.
hi, Chris
this is great post. i use single line but
can you create a poll for this topic?
I like the @Daniel @Ian Oliver style.
I’d be interested to see your point of view on organization (not only formatting) of CSS files, pros and cons.
Do people organize by selectors (each selector has multiple attributes) or by attributes (multiple selectors have the same attribute)?
Both scenario’s will cause some repetition of elements and attributes and will have different effects on readability and such.
Is there a consensus about best practice?
It really doesn’t matter how you choose to format your CSS because everyone is minifying before release anyway, right?
However, single line ftw!
Great idea to show common ways to format CSS. For me, single line is the best option.
Scripting languages seem to prefer this format
Compiled languages such as c#, c++ seem to follow this format
That is the format for me as well.
It is more readable because it clearly sets out a group.
When you are checking that you have all the opening and closing braces correct you can look up and down rather than having to scan across to the random length of the method name for the start brace.
I use the single-line format.
It irritates me when I download someone else’s CSS because most often it’s the Multi-Line and I feel compelled to go through and re-format everything. Im very nit=picky about my development, for better or worse.
The single-line with indenting look. Have to give it a try..
haha… thats good. Reading your post I felt so much myself. Me too – when I have to work with someone elses multi-line I feel like start to change it in single-line.
Multi-line with Indenting. ONLY way to fly.
It makes it so easy to scan the page and see how the hierarchy falls.
It’s straight Multi-Line Format for the fanboy, but I thought your approach in the css for your WP-Typo css was pretty cool.
I code in single line with each attribute in alphabetical order. I don’t tab to a new line because it’s a waste of space and if you use proper scoping it is already easy enough to read:
Anything else wastes space, but most developers work on smaller sites where bandwidth isn’t a huge issue. I have millions of visitors every day so I have to make sure my code is really tight…the hard part is working with contractors, co-workers, and agencies who have little experience writing css and often make my job much harder by not paying attention to the existing code. You’d be amazed at how many high costing agencies code like shit.
I typically use the single line with indenting.
But here’s the cool part…
I know most of you guys use Firebug, right?
It doesn’t matter how you format your CSS. Firebug uses the multi-line format!
So for initial construction of the file I type it quickly, organizing by relation. Then when I’m in tweaking mode, I just use the CSS ‘map’ in Firebug to see what I need to fiddle with.
Great post as always, Chris.
My setup is as follows:
First of all my style sheet has a header to cleary specificy which section it belongs to (I work with a style sheet framework that is modularized by sections).
Secondly it is divided into sections so that it is easy to find the selectors that I am looking for.
The selectors is written in a single-line format where I declare the mostly used properties in the same order. Not alphabetically, just in a way that makes sense to me:
#selector { width height padding margin position display font background float }
This way I know where in the line I have to look for a given property.
This post comes as quite a coincidence to me as I have only recently changed from multi-line format to single-line format, my initial concerns were that it would be harder to read, but it turns out that it makes it a lot easier to find the tag, id or class you are looking for.
Might move onto single-line format with tabbing next! woo!
I do this.
I’m a multi-liner. Even in long style sheets I don’t find myself scrolling, since my workflow involves inspecting an element in Firebug and then jumping straight to the relevant selector using ⇧⌘L (Go to Line…) in Coda.
I usually use Multi-line Format with Indenting when I’m working on projects. for live websites I usually compress the CSS with YUI Compressor.
Just thought, that someone should mention, the nifty little CSSTidy-tool, that will help you format your CSS…
http://csstidy.sourceforge.net/
Man, some angry people when it comes to CSS formatting.
I tend to stick with the standard multi-line format but just as important is commonality between those multiple lines. Making sure the items appear in the same order and in my opinion the order of importance makes it really easy for me to find what I need when I need to review my code.
I like the multi-line format. If I need to make my stylesheet load quicker, I just compress it when I’m done making all the changes I need. With Textmate you can always expand it later. For me, multi-line is easier to read…my reset is a one-liner tho, don’t change that much.
Multi-line seems the easiest for me to read and work with. Then it get compressed for deployment.
This is definitely one of those “no best way” things. You gotta work with what makes you the most efficient during development and then apply best practices when the files are on a live server.
I like the original, standard singleline the most. I never add a hierarchy to it because of the flexibility. A selector is a selector. Never had problems to find anything. Simple search – and there it is.
Multiline formatting with indenting up in here woot woot.
I use my curly brackets in CSS just like how I use ’em when I program:
i use multiline …. it comes from programming practice and feels at home :P (btw using new lines for { } comes from some programming languages and is default in some editors)
to find thing i hate to scroll but am a fan of ctrl+f (or firegug)
I tend to use a combination of multi line and single line, in that if the content between the braces stretches further than my window size when I’m editing I then switch it from single to multi so that I don’t have to scroll horizontally. I may have several windows open at once on my 24″ screen and have the editor on one side (approx 700px wide) and my browser taking up the remaining space, so that I can jump between the 2 quite easily.
I tend to keep things quite tight (reduce the amount of spacing) as I believe it speeds up the download of the css file(s). Not sure how much it usually saves, but it’s always nice to know that you can help a bit by shaving off a few bites here and there.
Oh to have
I’m a single-line format fan.
I always use 2 files, 1 development file, nicely formatted, and than one deploy file. Single line and compressed. Don’t let your obsessiveness for your structure and well organized files punish users.. It might not be allot that you save, but If you can why not do it..
Has anyone written a textmate macro to toggle between different formats? For example, I’d like to be able to toggle between “multi-line” and “single-line format with tabbing” using a simple keyboard shortcut. That’d be too rad.
I have been looking around for some time but no luck. I’m about cut my losses and write the thing my self. But, really, someone must have already written it. Right?
Lemme know if you have any leads
Like someone mentioned above, use styleneat(.com)
I’m all about the ‘Multi-line Format with Indenting’ coding but find my friend are all different. I find it most useful finding classes or IDs with my method but each to there own i guess :)
Great article Chris :)
hi frnd i might like to kon if i can use banner in css .
Hey, I use the multi line format… As Chris mentioned its easier for me to find what I am looking for in the code that way .. :)
I really like indented, multi-lined formatted css with certain attributes put together on a single line like margin & padding and width & height. I also like to put the attributes in alphabetical order – makes it simple to find what I am looking for and also mimic’s Firebug.
I strongly prefer the multi-line format with indentation, as it provides very useful hierarchy for browsing and editing stylesheets.
I think an issue of nearly equal importance is the order you place properties inside a declaration. I’m interested in what you do, whether it be alphabetical or structure-then-style.
I suppose it’s just something that everyone does a different way, and that’s the beauty of it.
I’m surprised no one here uses the table-style format:
Compare with the standard multi-line format; isn’t the above much more legible?
Won’t work if you indent the sub-elements or would it?
Thanks Chris. All the property values should be aligned, some didn’t above (“0px;”, “uppercase;”, “#897567”, etc), but hopefully you get the point.
Forgot “#fffffe;”, “-0.05em;” and “#eed2a1” =)
I guess the main difference between single-line and multi-line is what you want to read better : the selectors OR the properties.
With single-line, you can read all the selectors very easily, including the inherited selectors.
With multi-line, it’s the properties you read more easily. A better method for beginners who don’t know all the properties yet.
I prefer single-line, and I put my properties in alphabetical order to find them easily.
Yep I think that’s exactly the point. And what’s funny about it is I think those needs change. During development it might be better to have the properties easier to find, and then when you are “done” and the site enters the maintenance phase of it’s life, it’s probably better to have the selectors easier to find.
I use something close to “Multi-line Format with Indenting” but I only indent once to break things into sections, and I put the CSS declarations in an order that follows the layout of the HTML document with general stuff at the top and “extras” at the bottom.
Multiple indents didn’t really help readability all that much, IMO, because with things like “#nav ul ul li a span” and everything above it it was an indention overload. It ended up being kind of like semantic satiation — the indents just didn’t mean that much in the end.
I also arrange all my properties in alphabetical order. If Notepad++ didn’t have a shortcut for swapping lines I probably wouldn’t, but since it does (Ctrl + Shift + up/down arrow) I figured why not.
Sure, it’s not the best use of space compared to a single-line approach, but if we strive to have readable, semantic HTML I don’t see why the CSS can’t be as well.
Very good read and really entertaining comments. I’m sort of glad to see so many single-liners, working with multi-line formatted sheets was always a painful experience for me and many times I simply got to remove those nasty breaks for the sake of my sanity :) on the other hand, some of the folks working with my files were cursing a lot.
My single lines are never indented (too lazy to tab around), I just add longish titles to sections. I also got used to certain color coding, which makes everything readable at first glance. No particular order. I also work with screen resolutions of 1920 and 1600×1200, so my single-lines can be pretty long and I usually don’t have to wrap anything.
/*************CONTENT LISTS*************/
#content ul li, #content_jm ul li, #content_h ul li {background:url("../gfx/bullet1.png") no-repeat 1px 0; margin:0 0 5px 0; padding:0 0 1px 15px; width:100%; text-align:left;}
I prefer multi-line format myself, but everyone at my work uses single line, so lately I’ve started using that.
I use multi-line. But I combat the hard-to-read-ness of it by using the code folding feature in Textmate. If you code fold, it basically hides (on a toggle) anything between the braces. So I get basically a single line format, without the messiness of the properties being shown.
A lot of people seem to be mentioning the fact that you should
1. Minify/gzip before you go live
2. Be able to write in any style you want
3. Nest selectors
CSScaffold (http://wiki.github.com/anthonyshort/csscaffold) lets you do all that, and more, on the fly. Might save some time/headaches.
Optimizing code only for the sake of performance….. is not at all good idea rather we should focus in improving other bits of critical performance issues.
CSS should be very well formatted, indented and commented to make more meaningful for other developers who might be working on the project going forward.
Multi-line with indenting FOREVER!!!!
Single-line Format is hard to read but very good to make a smaller css size.
keeping css on one line is evil