Single Line CSS | Hacker News Reader

Single Line CSS

orderedlist.com

43 pointsgursikh41 comments

There's something to be said for both methods.

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.

This almost calls for some kind of plugin/script that converts this. It'd be insane to have a keyboard shortcut that will take the current selector and single-line/multi-line it.

css-tidy does a few different formats. You could alias a couple of different sets of options to e.g. `css-compress` and `css-expand` and just pipe your buffer through them.

Here is a tool that does just that.

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

Another benefit of this layout is that you can stack similar rules to make their relationships clearer. For example:

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

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.

May I self-promote and suggest Sass (http://sass-lang.org)? It's much older and less buggy than Less, and the currently-in-beta Sass 3 supports a CSS-style syntax (http://nex-3.com/posts/96-scss-sass-is-a-css-extension).

+1 for Sass. Sass allows me to apply the same modularity and reuse principles to my CSS that I do to my code, so writing it is much faster and editing it is much easier.

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

I usually do single-line inserts for global elements like blockquotes and links. For the rest - no way.

No No No. This completely screws up diffs and code revision tools.

While I agree with you, don't you think it's a little screwy to change your writing practice for the benefit of your tools? You should be able to write any way you want, your tools work for you.

Doesn't that cut both ways? I write the way I want by spreading the css over multiple lines, and the tools that I use provide a symbol view that lets me find selectors quickly and without fuss....even ignoring the 'Find' panel.

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.

Right, I agree that the trade-off of pretty CSS over good source control is a bad deal, but it's the fault of the source control tools for requiring you to write in a certain way.

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

I like to indent my CSS to resemble the structure of the DOM it's styling: http://addepar.com/style/style.css

This is really well formatted CSS. It combines the best of both worlds which makes it really easy to understand at a glance.

http://sass-lang.com/ is YAML-style and uses pure indentation, but is overly sugared.

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

Sass 3 will support a desugared syntax: http://nex-3.com/posts/96-scss-sass-is-a-css-extension

Someone made a LESS plugin for Coda, then turned it into a standalone app: http://incident57.com/coda/.

this is cool, thanks for sharing

no problem :)

I've tried this method and have three observations:

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

I don't mind compressing css after you have written it but if your only reasoning is finding selectors I must disagree.

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

I think this is something which you should let your IDE handle. Most decent IDEs have code folding and quick search.

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.

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.

Makes it easier to sort in Vim; 'ggVG!sort' will sort your css alphabetically:

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

Would you mind sharing this script with HN'ers?

  #!/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";
  }

Or just see if your favorite editor has a folding mode.

would a folding mode turn a CSS dec like:

   .selected {
   color:white;
   }

into .selected{}

or .selected { color:white; }?

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

His main complaint was finding selectors ... so, if we're going by the article that shouldn't work fine.

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.

Vim's folding shows the first line, so it works fine there.

Or some navigator (map) like there is in Netbeans.

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.

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

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

I love sass, a different approach.

I blogged about this a while back at http://devgrow.com/best-bet-css-practices/

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.

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

You don't need an IDE, just a damn browser with a web inspector.

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.

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.

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.

Love it, I've been using the single line technique for about 6 months now (I used multi-line for years prior). It's definitely easier to scan.

How about using a hybrid method? Use single lines for selectors that have at most 2-3 attributes and use multiline for >3 attributes.

I'm doing it exactly this way as long as I can remember for compactness.

Reply on news.ycombinator.com