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.

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.

http://www.newmediacampaigns.com/page/single-line-vs-multi-l...

    div.red   { background: #f00; border: 3px solid #c00; }
    div.green { background: #0f0; border: 4px solid #0c0; }
    div.blue  { background: #00f; border: 5px solid #00c; }

I played with a few other CSS processors over the last few years (Less, Moonfall, one or two others) but Sass is clearly in the lead. Thanks nex3 for a very useful tool.

(Oh, and FWIW, I use it on a Perl website. You don't need to be on Rails to use Sass.)

Im fascinated by the idea that I should break something as important as effective source control to fix a problem as simple as finding a specific selector in a file.

Edit: In my original comment (can't edit it now), I should have said "isn't it screwy to need to change your writing practice..."

http://github.com/cloudhead/less is a purer subset of CSS where you just nest rules inside the curly braces.

* 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.

* I wasted too much time trying to correctly align/indent my code

* 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.

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.

-a keyboard editor

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.

Let the IDE take care of abstracting away the actual file structure. Let your build process take care of minifying the css files.

Conventions are good in programming, but single-line css looks like a bit too extreme trade-off.

.bar .apple {...}

.foo .apple {...}

.foo .banana {...}

.foo .cherry {...}

(I also have a wee script that sorts the declarations alphabetically too.)

I prefer the style, I find it much easier to write, edit and maintain.

  #!/usr/bin/perl -w
  use strict;

  # from selected block in vim: !scriptname.pl
  while (defined(my $line = <STDIN>)) {
    $line      =~ m/^(.*)\{(.*)\}/;
    my $element = $1;
    my @list    = split /;/, $2;
    @list       = join ';', sort { $a cmp $b } @list;
    print STDOUT "$element" . "{@list}\n";
  }

And also question why you have 1000+ lines of CSS.

news.ycombinator uses only 31 selectors. And it looks.. well maybe not great , but very readable and very useable (I like it a lot).

And I think it's better to have more classes defined in your DOM-object than doing the same stuff multiple times. I mean, most of the time widths, margins and paddings are reusable. So why not create classes for them.

   .selected {
   color:white;
   }

or .selected { color:white; }?

Most folding modes that I've seen makes the block hidden, which is nothing like what single line CSS is.

But really, if you plan your CSS instead of applying edge-case band-aid over edge-case band-aid, this becomes a complete non-issue.

However ocharles is right about the fact that it screws diffs (as long as they are per-line oriented).

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).

...not that there isn't a use for organizing a certain way (like this article describes) in the first place.

You have two independent compatible implementations of hypermedia lisp machines, both open source and installed on hundreds of millions of end-user machines. You can click any live object to inspect it, with tracing debuggers, REPLs, I/O analyzers, multiple domain-specific object browsers, etc.

There's not really room for anything between that and a text editor.

I still find myself using Ctrl+F a lot when editing CSS. Sometimes even growing it further than needed as Ctrl+F becomes mundane.

Should CSS be approached more like code rather than like markup? Haven't tried that yet.