More is better - at least when it comes to lines of CSS. I personally prefer putting each CSS rule on their own line in my CSS files, but some people have advocated the use of putting each of your CSS rules on a single line, like so:
#wrapper {width:800px; margin:0 auto;}
#header {height:100px; position:relative;}
#feature .post {width:490px; float:left;}
#feature .link {width:195px; display:inline; margin:0 10px 0 0; float:right;}
#footer {clear:both; font-size:93%; float:none;}This single line approach makes it easy to scan through a stylesheet and find the selector you want to modify. But that’s also about as far as the benefits go for this approach.
Finding a particular attribute in that list is hard, and it can get really hard to quickly grasp what a rule is doing. For example, this actual rule from substancelab.com is not all that easy scan, is it?
.more { color: #ffffff; background-color: #326880; display: block; font-weight: bold; padding: 5px 10px; text-align: center; text-decoration: none; color: #326880; text-shadow: #163440 1px 1px 2px; -webkit-border-radius: 5px; -moz-border-radius: 5px; border-radius: 5px; }The order of attributes in a CSS rule matters. While jumbling them all together in one big pile does preserve the order, it also makes it harder to change the order. Instead of cutting an entire line and moving it up and down, you now need to slice out the bits from the middle of some long line, and try to find the proper position in that same, hard to scan line. Not optimal.
Source control management software is generally speaking line-based. If you change one little thing in a single line rule, for example the mistake in the .more rule above (you did see that, right?), the entire line will register as having been changed.
While not a big deal initially, it makes a huge difference when you want to merge changes with another branch or someone elses changes. Two individual lines that has been changed can easily be merged, while two changes to the same line will cause a conflict. Conflicts are bad, mmkay?
Seriously, who scans through a CSS file anyways? Even when put into single lines, the stylesheet from bornibyen.dk contains 600+ lines - that’s too many to comfortably scan through.
And why would I scan through it when I can reliably jump to the rule I want using TextMates “Go to Symbol” - your editor does support something like that, right?
Speaking of editor support, here’s how a multiline stylesheet looks in my editor:
.header .gradient {…
.header .branding {…
.header .branding .logo {…
.header .branding .logo .tagline {…Absolutely perfectly scannable if that’s what I wanted to do. And if you want to edit one of the above a simple keypress unfolds the entire rule. It’s almost magic, and it plays nicely with your SCM, is easy to scan, the attributes are decipherable, and it’s easy to change.
For once, more is indeed better.
Well i guess its a matter of preference. I personally prefer the single line, but these are certainly valid points to why you wouldn't :)
The thing I don't get is why you find it preferable? Code folding (as done in TextMate) gives you the same thing with none of the disadvantages.
I dont actually use code folding at all (never gotten used to it i guess), but it is certainly the better alternative
[quote]Who scans anyways?[/quote]
Well, I know at least one CSS Ninja who does; by the proper use of property-placement and whitespace this guy has an amazing overlook, spotting issues at a glance, whipping up prototypes in HTML/CSS faster than you can draw them by hand. Besides, you can't always rely on having TextMate at hand, so I'm not sure, I buy into the code folding argument.
The SCM issue, however, is a very valid point and CSS gurus like Eric Meyer and Nicole Sullivan both do seem to prefer the multi-line approach so it's not a matter of expertise per se.
As a Jack of all trades - expert in none ;), I'm a bit AC/DC myself, usually just going with the given standard in the project I'm involved in, but when push comes to shove, I think I'm with you here, Jakob.
Totally agree. Single line CSS is unreadable and highly unmaintainable. It should be shunned.
Kenneth, any editor worth its salt will have code folding support.
Readability and the SCM argument should be enough to convince everyone multiline is the way to go.
I couldn't agree with any of the reasons you stated. What it comes down to is this: if you have widescreen monitor it is better to write single-line css, if you don't have one stick with multi-line, everything else is just not that important especialy refactoring and subversion control. I mean, really, is it possible for two people to work on a same css file intensivly and get no conflicts? Answer to this question is so obvious..
It is most definitely possible for 2 or more people to work on the same CSS file. Sure, it might not be easy, but with a bit of discipline and conventions it can be - and has been - done.
I completely agree. I am constantly having a holy war in this office over the "benefits" of single line CSS (I'm very much multiline). I find that those that are "into" multiline CSS seem to have less experiance or confidence with actually using their editor.
It's gotten to the point that I now check all front end developers' CSS files and those that do commented, indented multiline are put to the very top.
Bizarrely I am often told that the single line css is done because its "more efficient". These people seem to think that a couple of hundred extra newlines is going to cause some sort of massive slowdown. When I suggest they minify their CSS for production instead and keep it human readable I get a blank stare.
Of all the holy-wars in web-dev this is the one I'm most likely to get completely wound up by.