There's something to be said for both methods. <p>Multi-line CSS is easier to read/edit when you're actively building something because you are constantly moving properties within and across selectors. You're not likely to need to search for a selector because you probably have most of it in your head since it's all been written recently. In other words, inserts have greater importance than reads.<p>When you're maintaining a site, single-line CSS may be best. You may have forgotten the lay of the CSS, so the structure of it should be understandable at a glance. This is enhanced by the readability of comments, which have more impact when you can see all the CSS they are referring to at once.
Another benefit of this layout is that you can stack similar rules to make their relationships clearer. For example:<p><pre><code> div.red { background: #f00; border: 3px solid #c00; }
div.green { background: #0f0; border: 4px solid #0c0; }
div.blue { background: #00f; border: 5px solid #00c; }
</code></pre>
In multiline mode, it might not be so clear that they are related. We are experimenting with lessCSS here, in theory it might make this go away, in practice lessCSS seems quite buggy, so we are not using it for much yet.
I like to indent my CSS to resemble the structure of the DOM it's styling: <a href="http://addepar.com/style/style.css" rel="nofollow">http://addepar.com/style/style.css</a>
I've tried this method and have three observations:<p>* Navigating to a given style attribute for editing was slower than standard format, presumably because instead of browsing to attributes via up/down arrows, I was now using left/right. The home and end keys also became less useful. Likewise, mouse movements were slower because not all the attributes were left aligned. I also use a 16+ size font, so narrow left-aligned CSS suits me well.<p>* I wasted too much time trying to correctly align/indent my code<p>* I wasn't quickly able to recognize patterns in the CSS. So my id:class ratio was higher than normal because I didn't have that consolidation.
I don't mind compressing css after you have written it but if your only reasoning is finding selectors I must disagree.<p>C-s is for navigating and the more traditional styling leads to easier editing as it is easier to move across lines than across words.<p>-a keyboard editor
I think this is something which you should let your IDE handle. Most decent IDEs have code folding and quick search.<p>Also keep in mind that many elements in your website can have an average of 4-6 attributes. If you are using browser specific enhancements or hacks you can easily have more than 10 attributes for some of the elements. Now think about performing that dreaded horizontal scroll in your editor to find some of the attributes.<p>Let the IDE take care of abstracting away the actual file structure. Let your build process take care of minifying the css files.<p>Conventions are good in programming, but single-line css looks like a bit too extreme trade-off.
I don't see a point to this. Textmate can collapse all of the blocks, so you get the same effect, without losing the readability if you want it. Also, who visually searches a css file? I just use CTRL-S in Textmate or Emacs.
I've used single line CSS for 2+ years now. I find it better at both reading and inserting/edit (I find it weird to read/write Multi-line ones). I used to sort by layout-appearance (important layout first, than appearance), but have now switched to A-Z sort of properties for maintainability (if others have to look at your code, you have to think about them).<p>However ocharles is right about the fact that it screws diffs (as long as they are per-line oriented).
I blogged about this a while back at <a href="http://devgrow.com/best-bet-css-practices/" rel="nofollow">http://devgrow.com/best-bet-css-practices/</a><p>For practicality I find myself using multi-line CSS during development and use a CSS optimizer before going live, which makes the code look a bit cleaner and reduces overall file size (albeit not by much).
decent IDEs like Aptana will make browsing stylesheets much easier. like methods in an object, it lists all definitions and allows for alphabetizing and clicking to jump to that specific definition.<p>...not that there isn't a use for organizing a certain way (like this article describes) in the first place.
Have used single-line since 199x when we saved bytes by writing compressed css, and switched to expanded several years ago just because it is easier to read and modern debuggers/editors use that style. Don't see any reason to revive 'oldskool' practices which are worse in readability.
Will try that.<p>I still find myself using Ctrl+F a lot when editing CSS. Sometimes even growing it further than needed as Ctrl+F becomes mundane.<p>Should CSS be approached more like code rather than like markup? Haven't tried that yet.