July 12, 2007
Single Line CSS
I've been going against convention when creating my CSS files for over two years now. I put my selector, brackets, and attribute/value pairs all on a single line in my CSS file. And I love it. Let me show you why.
To give credit where it's due, this technique was originally show to me by John Nunemaker. And when I first saw it, I likely responded the same way you will shortly. “Um. No thanks, that’s ugly.” But the more I saw it, the more I saw it’s usefulness, and soon enough I was writing my CSS files the same way.
Enough preface, let's see some code
Typically, when you see css code, you see it like this:
#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;
}
All well and good. You can easily scan down this list, find your selector, then scan down a short list of attributes to get to the values your looking for. But imagine now that you have over 200 selectors, each with a laundry-list of attributes. That's quite a mess to search through. My issue with CSS files like these is when they get large, it becomes very difficult to scan the document for a particular selector. They're all separated by loads of attribute and value pairs. So what if we took out that separation, and put each selector, and it’s attributes and values all on the same line?
#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;}
Now that is easy to scan through. To put this into a practical example, one of my single-line stylesheets comes in around 307 lines. Converting the same stylesheet to the normal CSS formatting grows that to a whopping 1167 lines! 6-8 screens of CSS vs 22-25. That's quite a difference.
“But Steve,” I can hear you say, “ now the attributes are hard to scan through.” True, it's not as easy as it was when they're lined up like the previous example. But think of it this way: a large CSS file might have hundreds of selectors, but each of those selectors may have only a few attribute and value pairs, or maybe as much as 10 to 12 if it's very stylized.
So, which would you rather spend your time searching through? A list of hundreds of disjointed selectors to find just the right one you're looking for, or easily scan 200+ selectors, and then spend an extra second or so looking through the few attribute and value pairs defined within?
I would at least encourage you to give it a try. This is just a little tip that saves me loads of time when creating, and especially editing, CSS, so I thought I'd share.
This is definitely just a matter of personal preference, and either way is just fine—but I do have one very practical reason why I prefer to have one attribute per line: error checking. If you validate your CSS, most any tool will respond by telling you what line your error is on. If you’ve got one attribute on that line, then you know exactly where the problem is. If you’ve got 15 attributes on that line, the line number wasn’t much help to you.
This doesn’t mean I think you shouldn’t do one-selector per line. It’s totally up to you. If you like it better, then go for it. I just wanted to point out the one practical reason I know of for choosing one way over the other.
July 12th, 2007
Good point Jeff. Although I would say that when error checking, you could put the attributes on separate lines if you come up against an error, then put them back on one line when you’ve got it fixed.
July 12th, 2007
I think there are merits to both ways. I prefer the multiple line route while developing. As Jeff mentioned, it helps with error checking. Also, depending on how you setup your stylesheet, finding things isn’t always a chore. Using comments and organization from the beginning will help the organization process. I guess I never really scroll to find things, I just use find/replace.
I actually like the one-liners at a glance look – it just seems easier on the eyes, especially as you have more attributes and such.
All of this can change when it goes to a live server – it can be optimized and compressed for that, but for development I like to be able to see it all.
It all comes down to a matter of preference and what works for you…
July 12th, 2007
Very interesting article! It made me think :) I couldn’t do it though, I truly hate horizontal scrollbars in my code editor, and your approach will definitely result in me having to deal with horizontal scrollbars.
July 12th, 2007
Or you could use a tool like CSSEdit that makes Selector browsing and even organization a cinch!
http://tinyurl.com/2f3whl
July 12th, 2007
The way I work with CSS that gets a bit of both worlds is writing my styles in the typical CSS formatting. But I use an editor which allows me to collapse blocks of code. This way with a single keystroke I can collapse all my styles and just be left with the selectors. Then another keystroke and it is all back nice and neatly formatted for debugging.
July 12th, 2007
I agree with Joshua. I tend to keep my selectors multiline, and then use CSSEdit to sort them into groups which makes for incredibly easy browsing.
July 12th, 2007
Another nifty solution is to edit your CSS using a sweet app like CSSEdit that creates a visual list of all your selectors. This allows you to browse selectors and to keep a full readable code.
In fact it even allows you to create folders to group your rules… and yes it includes validation too.
The only drawback is that you need 2 applications to edit your code. I’ve been using CSSEdit for a while now and I can’t go back to edit CSS in my usual text editor, even my beloved Texmate
July 12th, 2007
Nate: True, optimizing for a server is very different, but when developing locally, this really speeds up my development.
Harmon: But maybe if you use this way your files might not need vertical scrollbars. :)
Joshua: I prefer to hand edit the CSS, as it’s faster for me than any other solution.
Chris: Does it remember it across sessions? Or when you come back to change things a week later?
July 12th, 2007
Oups, by the time I wrote my reply and answered the phone it seems other CSSEdit fans poped-up :)
July 12th, 2007
Hey Steve,
I think that 99% of my development of CSS follows this process:
1. Write a selector in CSS with 1 attribute, save the file 2. Switch to firebug and flesh out the css selector 3. Copy the selector and paste it into the CSS file
For debugging I almost always start with firebug and click the element that is having a problem, the line number of all the selectors effecting the element are listing right there. Just a simple line jump into your document.
That’s why I prefer to use the former method that you describe rather than the latter.
Just my 2c :D -Cam
July 12th, 2007
This is why Macromedia included Ctrl+F. :)
July 12th, 2007
Have to agree this is a personal preference – but I moved away from the method you use after getting sick and tired of horizontal scrolling to find attributes. I started using a hybrid method along with search flags. Organising CSS, revisited
July 12th, 2007
I am a fan of your method because it seems cleaner to me. I personally can’t stand scrolling forever, I’d rather just give the file a quick glance.
July 12th, 2007
Ha, I even predicted this response. I reacted the same way when I saw it, and it took a while to try it out and really see how it’s helped. That’s why I said, just sit on it for a little bit, and maybe give it a try. New things are good, right?
July 12th, 2007
I like to edit my CSS by hand, but I only use whitespace when necessary because I use CSSEdit to scan through the selectors. However, trying to debug something is a pain, so I might consider this line-by-line method for future projects.
July 12th, 2007
I exclusively use CSSEdit for my CSS editing needs. That’s not to say I use the magic enter values into boxes to make things happens (I pretty much never do), but I do use it’s browser, and make quite extensive use of the group feature, now that makes dealing with large CSS files much easier than “one rule per line”.
As to the editor that remembers collapsing code blocks – TextMate does that, and it stores it in file metadata somehow, so it survives practically forever.
July 12th, 2007
I’ve adapted to using both intermixed. I know that single-line is great for keeping my code compact and scannable, but I also break out attributes to multiple lines when I get into my more complex elements.
Common and simple selectors are single lines and usually grouped together. More complex selectors with many attributes are grouped and broken into multiple lines for readability.
July 12th, 2007
...and here I always thought I was an oddball because I prefer having all my CSS rules for a selector on one line. I feel better now Steve, thanks.
For about 2 years now (coincidence?) I’ve been structuring my CSS like this – It might look like a mess, but the indentation level in the layout section indicates the depth of the selector. Sometimes, if the list of attributes gets very long and I have to do a lot of side-scrolling, I’ll break it down, but I can scan this format much faster. Now, that example is a relatively short screen stylesheet because the site is pretty simple. The CSS there takes up 78 lines. If I broke all the attributes into seperate lines though and added a break between every selector, the same sheet would be 301 lines long, and that’s without the comment blocks. So yea, I’ll keep with the single-line style.
@JCroft-”Error checking? We don’t need no steeenking error checking!”
July 12th, 2007
When first learing CSS back in 2003, I learned to create it in this fashion. I didn’t know that it wasn’t more widely used and kind of surprised to see people have never tried it or heard of doing it this way.
For the smaller sites I work on, I tend now to code with attributes on their on line and then have separate CSS files, for layout, presentation and what not. These separate files are very easy to scan and aren’t that long.
For larger applications like my full time job the stylesheets are huge and we haven’t yet got to the point where I have been able to streamline it the way I want and break into separate stylesheets. I prefer these to have all the CSS for a selector on a single line.
I think most of the people that post they like their selectors on multiple lines haven’t yet worked on a ginormous web site application where the CSS is thousands, granted most of these types of applications could be streamlined tremendously but like in my situation, I came into like this and plan to turn things around but the CSS is still huge.
I would like to try the way Jason does it, I have seen and read about this many times, it looks pretty crazy to me but I’m sure once you work with it, it explains itself. I’m also with him on ”Error checking? We don’t need no steeenking error checking!”
July 12th, 2007
What this highlights again is that CSS is not easy to manage, especially on larger sites. There’s no easy solution – one approach entails right scrolling, another scrolling down the page.
Handing code to another developer I would favour multi-line but there are tools that can automate single line to multiline.
One benefit you didn’t mentioned was that single line will also shave a few kb’s off the files which on high volume sites will save on bandwidth bills.
July 12th, 2007
Steve: Just to clarify, CSSEdit is excellent for hand-editing CSS. I won’t touch CSS any other way really. It’s got great code-completion, and the grouping/organizing is a definite bonus.
July 12th, 2007
I have to agree with this article. This is the approach I use with my CSS and I find it very easy to find what I need.
July 12th, 2007
@Dan Shields: Careful with suggestions like that about not dealing with large CSS.
My day job involves working on a group of websites, for which the CSS totals 5232 lines (95% shared across all sites). It’s kind of spread out across files (global, then the IE overrides, then per-section CSS).
Where possible I’ve added the /* @group */ “tags” in CSS Edit. This makes it much easier to work with.
Personally I find TextMate (and similar editors) that offer a symbol list to be easier than cramping my CSS files.
July 12th, 2007
Sorry if that came off as saying people haven’t worked on large applications, I didn’t mean it that way. I to work on the same type of environment as you, with about 20 or so websites. When I came here the CSS was coded with attributes on single lines and they were about 5k lines long, I just didn’t like this. Like in the article it’s really anyones preference and my preference is for large websites, do single line CSS to save scrolling and file size, and for my side jobs or smaller projects have multiple lines for attributes and break the CSS files down into different stylesheets.
July 12th, 2007
I’m with Jeff Smith—CSSEdit is the only tool to touch CSS for me. I hand-code my CSS in there using the multi-line code approach but I like the selector sidebar very much for a quick scan through the file.
July 12th, 2007
This post made me laugh right away because I did that too forever until I started working with someone else who would have to sort through my CSS. He was adamant that I stop doing that. I was like, “what? you can’t read that?” We both sort of half laughed it off and I bent his way.
I suppose when we’re freelance and we’re likely the only ones manning the stylesheet we can do it however we want, and personally, I have no problem sorting through long lines of attributes, particularly because I tend to have an order in which I put them each time (positioning, size, colors, etc). But, to look through your code, it might be tough because I’m not used to your style.
For the record, I’m all about condensing and saving space, but I’m more gung ho about helping others keep their sanity when working with me! :)
July 12th, 2007
I’m not sure it is totally a matter of personal preference, though I’m sure that is a lot of it. It appears though for design elements with only a few attributes, the single-line css works beautifully. However, if you have several, more complicated elements with more attributes, the traditional multi-line format seems to be cleaner, especially when you have several complicated elements in a reasonably short CSS file. Besides, scrolling is easy. ;)
I know you covered this, but I thought I would offer my 2 cents.
July 12th, 2007
no thanks. And I agree with jeff croft. I do all my initial css writing in Chris Pedericks webdev toolbar’s css edit sidebar and all my css debugging with firebug and the fixing of the bugs in BBEdit. I need every attribute on a separate line because it makes it extremely easy to find the line in BBEdit once firebug tells me what line it’s on.
Also BBEdit generates a drop down menu of all selectors in a css file.
Try a better editor than whatever you’re using now.
Your comment system is sweet.
July 12th, 2007
Well my approach is a rather hybrid one.
When it comes to to a declaration with more than one properties, always expand it to as many lines as the declaration. If it’s just one, one line will do it.
There were times I was dealing with a css file including another 10+ (back in 2004 days). Then I thought that was cool. Now I believe being practical and consistent in CSS is the key.
July 12th, 2007
This reminds me of the indention method for css I wrote about in ‘05… which even then wasn’t something new, but definitely worth sharing.
July 12th, 2007
Forgive me if this was already mentioned… I’m a single line writer myself… One thing you might want to consider doing is writing your attributes in alphabetical order… Doing so helps you to scan through single lines quicker and keeps things logically ordered.
July 12th, 2007
I wrote the TextMate CSS reformatting actions. Select some CSS, hit ctrl-q or ctrl-opt-q to reformat your CSS inline or expanded.
However I usually always use CSSEdit. Jan is the man.
If you use subversion, it’s best to use the expanded form of css. Much easier to see exactly what modifications were made.
July 12th, 2007
Couldn’t agree more. For a site with lots of selectors/rules, this is definitely my favorite way to go. As many have mentioned, grouping selectors is a great way to keep a css file organized. The problem I have with multi-line rules and grouping is more often than not a group won’t fit on one screen, and as soon as the group isn’t visible as one unit on the screen, its lost its valuableness for me.
Keeping them on one line generally leads to groups being visible in whole on one screen, and helps me stay more organized. Nice post, thanks for the insight.
July 12th, 2007
Heh, it sure is a matter of personal preference I guess, but I’ve always coded CSS this way (and that’s for the past 6 years or so, actually) – even when following other people’s example code like at ALA, when it comes time to implement I always use single-line rules, grouped into relationships so it’s easier to follow and maintain (and even if the less whitespace leads to even slightly improved download size, that’s a bonus too!).
July 12th, 2007
Steve, sorry for replying so late to your reply, it’s been a busy day.
I handcode my CSS as well, it just so happens that CSSEdit is the most amazing text editor for CSS. Sure it has some nice GUI functions as well, but I haven’t seen them in ages because I never use them. Check out the link that I posted in my previous comment, it’s a screenshot of my typical CSS workflow. I think this is why you’ll find so many people recommending it, not for it’s GUI capabilities but for its fantastic CSS aimed text editor.
A couple things really make it stand out in this instance:
1. The visiual list of selectors on the right hand side are not only easy to browse with their own frame and scroll function, but they are actually styled the way you define them to be in CSS! That’s huge. I might not remember which header number I named something, but I will remember it was big, red and bold. Easy to find.
2. The standard cocoa search function in the toolbar is absolutley priceless. Sure, when working on a blog design, it’s easy to get through a CSS document, but when you’ve got one CSS document that’s got thousands upon thousands of selectors that targets a site that’s been in development for years, it would be impossible to find anything without that awesome search function. Cmd+F wouldn’t even fill a gap in this situation.
July 12th, 2007
I use Eclipse with the Aptana IDE (http://aptana.com/). It’s CSS syntax highlighting is fairly good, but the best thing is that it has an “Outline” panel which shows all your CSS selectors at a glance – so I don’t have a problem with scanning them. Or if I know what I’m looking for then I’ll hit Ctrl+F and type a bit of the selector and viola, a couple of taps of the enter button and I’m at the selector I want… So I’ll always be a multi-line guy – that and horizontal scrollbars shit me to tears.
Anyway, like has been said before, it’s personal preference!
July 12th, 2007
I also prefer single lines but recently discovered my co-workers were going out of their way to put the CSS back to a single property on each line. So now I am writing a mix of the two styles; multiple lines but I group similar properties together. For example, font-size, text-align, color, etc are on a line together, box model properties margin, border, and padding on one line, etc, etc, etc,. Everyone seems happy with this.
July 12th, 2007
I used to format my CSS the long way, but I’ve tried this way for several months now, and I like it a lot. As you say, it’s easier to find the selectors, and that is usually what I’m trying to find. I also put my attributes in alphabetical order (they’re easier to find) and if the line gets too long, I’ll wrap it down and tab it over.
July 12th, 2007
I just made this switch myself. However, I like a space between the braces and attributes:
a:hover { color: #fff; background-color: #000; } vs. a:hover {color:#fff; background-color: #000;}
I think it makes the attributes appear to be less “packed.” A personal preference for a personal preference.
July 12th, 2007
As someone who’s been programming one language or another for some thirty odd years, as coding habits go this is such and incredible step BACKWARDS in viewability the only thing I can think of to rival it is the old ‘one line basic program’ competitions in the various old-school magazines like 80 Micro or Byte.
I look at those and honest to god cannot tell where one attribute begins and the next ends – and it gets WORSE when you add spaces around everything – strange as it is more spaces makes it even LESS clear. (since you are putting breaks in everywhere, the actual separation of property from value is unclear)
Sorry, but to me, this is a total /FAIL/ – Makes validation harder, makes moving a handful of properties from a container to it’s child or from it’s child to it’s container a pain in the ass (home, shift-down a few times, ctrl-x much?) and it’s nothing but a mess when it gets wide enough to wordwrap… or an even bigger pain in the ass when wordwrap is off… much less the disaster you get between different programmers who have their tab stops set to different values (I’m a two space guy, your reallly old school guys are three space, the default in most editors is five, except for your emacs nutjobs with their 8 space tabs… Which means your nice neat columns have a 75% chance of not even lining up when someone else opens it up. All in all this ‘other way’ of formatting reminds me of Carlos Mencia’s favorite 3 digit hexadecimal color.
... and I just don’t get what’s so hard to read about the ‘normal’ method – it’s clear as a bell to me while ‘condensed’ just looks like a sloppy lazy mess.
But as with anything, YMMV.
July 13th, 2007
I agree, Steve. I moved to this method after my CSS files started getting ridiculously long, and wouldn’t want to go back. For me, the most significant advantage is the ability to immediately see the relationships between parent and child elements.
For example: #nav {float:left; width:600px; height:200px;} #nav ul {float:left; height:100px;} #nav ul li {display:inline; list-style-type:none;} #nav ul li a {color:#666; text-decoration:none;} #nav ul li a:hover {color:#900; text-decoration:underline;}
Whenever I go back to a multi-line CSS file, I miss the ability to quickly be able to see these relationships. This also helps me eliminate redundant attributes or quickly move attributes up or down levels of specificity. It also can tend to show you where you have unnecessary classes/divs; and if you are somewhat consistent in how you order your attributes, can even help you compare differences between related elements (such as widths on floated elements that directly effect each other).
July 13th, 2007
Personally, I have adopted a combination of both methods and make use of simple convention. I collapse “similar” or “related” selectors on one line making use of the following convention.
On the first line I group any selectors relating to the position of the element, the second line relating to the size and the third line for anything else, this makes for easy scanning. If there are only a few selectors I collapse them onto one line.
For example:
div.example {
}
I took inspiration for this method from a post on Matt Wilcox’s blog
July 13th, 2007
@Natalie Jost – Same here. The trick to this is being a bit anal and organizing your attributes in a similar fashion. I’d just like to say that Steve and I are right and everyone else is wrong. :) Just kidding. I’m not surprised at all by the outcry. Everyone that I have initially shown this too has poo poo’d it.
However, everyone that has tried it for a while and been strict about the way they layout your stylesheet has permanently switched to the one liners. It just feels cleaner. A few more tips for one liners:
Viva la one-liner!
July 13th, 2007
I can agree with all of you. Having coded CSS for several sites by hand, no dreamweaver, etc. to help out, it makes it easier to do them as one line for me. This helps to keep the scrolling up and down with the mouse or roller to a minimum, plus this provides an easy method to separate the styles into areas that they apply to. I break them down into a division for global, main body content, then header, content and it’s divisions, and then the footer. This also helps to make it quicker to find what I’m looking for.
Is there a tool out there like CSSEdit for the PC? (yep, I’m stuck in PC hell…don’t laugh!)
July 13th, 2007
I’ve been doing this for a while now—and I love this method. I’ll go you one further and say it’s proved to be even more useful to indent selectors.
For example, if you have a division with a paragraph in it and a link within the paragraph, I’d do this:
div {attributes} p {attributes} a {attributes} nextdiv {attributes}
I don’t know why more CSS isn’t written this way. Code indents are good enough for JavaScript, PHP, .NET, JScript, JAVA—everything. Why not CSS?
It’s my choice. And it’s all personal preference since there are n number of ways to skin a cat.
July 14th, 2007
Ok, answered my own question and found a great resource listing of editors, beautifiers, etc:
http://www.smashingmagazine.com/2007/07/12/time-savers-code-beautifier-and-formatter/
Hope this helps someone else too!
July 14th, 2007
I don’t know. I really prefer multi-line, organized only by alphabetization (selectors and attributed within them). It’s still easy to find things—just find the starting letter.
July 14th, 2007
I have found myself lately coding on windows. Not that I dislike it. It’s just been so long since I left the windows flag behind got a penguin as my pet. I’ve found a few textmate clones to have a very interesting feature. Namely, “e text editor”, when you click on the rightmost blank place on the status bar, welcomes you with a list of selectors in css, or classes in python (I did not try with more languages so far).
So now, it’s a matter of taste, and the tool you use. Since my editor on linux does not have this feature, I’ll try it on my next project, which is just waiting for some time of mine.
Thanks you for sharing, Steve.
July 15th, 2007
Looks like I inadvertedly chose the same CSS coding style as you! To be honest, I never realised the other way was so common.
To me, it makes perfect sense to have everything on one line. Reading through, I’m generally looking for a selector first, and then from there I look or the attribute, so it makes sense to have selectors in a nice list format – it makes it a lot easier to spot things when I’m scanning down the page.
So – thanks for giving me something to reference next time any of my colleagues moan about my ‘bizarre’ CSS coding style! :)
July 16th, 2007
Certainly an interesting approach. I have to chime in with using CSS Editor with its groups and real-time search are quite helpful. You should be able to switch easily between the two forms with its “Re-indent” feature, though I haven’t tried this single line approach yet.
July 16th, 2007
I use single line also. Have for a couple of year now, and I indent sub selectors such that:
div#navigation { } div#navigation p { } div#navigation ul { } div#navigation ul li { } div#navigation a { } div#navigation a:hover { } div#navigation a:visited { }
July 17th, 2007
This preview of the comment is awesome. Unfortunately it was not accurate.
Here is what I was going for.
July 17th, 2007
Overall I prefer a style that favors selector comparisons over property list comparsions.
To mitigate the reduced readability in the property list, I tried out your style with two spaces between each property/value pair instead of one.
Result: slightly longer lines but easier to disinguish individual properties, especially those with compound (single-space separated) values. Try it.
+1 for IDEs with multiple views, but we just as often need to see this stuff in the wild via view-source, so the “true” resource format still matters.
July 17th, 2007
While I agree with the format making it easier to find selectors, it does make it harder for a team of people using a version control systems that are line based, and allow concurrent editing, eg, cvs, svn and any distrbuted VCS.
Firstly, people are more likely to have conflicting changes since even changing different properties in the same selector is on the same line. This also applies if a person is adding a new property, where in the multi-line format the merge process would move forward without a hitch.
Secondly, viewing the differences between two revisions does not make it as clear what properties have been added/changed/remove without a more thorough examination.
Because of these reasons, I go for the multi-line formatting. I apply this not just to CSS, but my code as well. For example, I put opening and closing braces on a separate line in Java code. Although this does make the code much longer, using the features provided by your IDE to jump to different Java methods/CSS selectors reduces this issue considerably.
Eclipse provides CTRL-O for a quick view of the Java methods in the current editor, and I see no reason why the CSS editors wouldn’t also provide a similar mechanism. Another IDE feature that would be good here is code folding. If the CSS editors supported this, then you could fold the CSS at each selector. This would provide a very similar view to what you are talking about, yet allow you to expand to an easily readible multi-line view of the properties.
July 17th, 2007
As a sanity-preserving measure, I do indent rules for the nested containers: #left{a:b;} . . .#left li{c:d;}
If a project is not prone to surprises, I have all structure in the structure.css and colours/backgrounds – in colours.css. A very rare occasion, though.
July 18th, 2007
I use multiple-line CSS when giving it to clients, because usually that’s what they prefer. However, when I do work for myself (i.e. my blog, side projects, etc.) I use single-line.
July 18th, 2007
I used to be a big proponent of the multiline method but since I’ve started my new job it’s been all one-liner coding. It took me a while to get used to it but now I’m just so used to coding CSS that way I don’t think I’ll change.
The funny thing, at least to me, is that when I switch to coding JS or PHP or whatever my mind automatically switches back to the multiline, indentation style without missing a beat—and vice-versa when going back to my CSS.
As far as the whole “it’s more helpful doing multiline when fixing bugs” I don’t buy it. If you’re using Firebug do find the bugs then all you need to do is fix them right there, inside Firebug. Once you’ve solved your problem just adjust your styles in the real CSS.
Feel free to ignore me if you’re stuck in your ways though. Everyone has their own personal preferences :)
July 19th, 2007
Hello All – There is a simple solution to all of this!
Use an application to switch back and forth easily!
I use TopStyle Pro which has a nice little feature called Style Sweeper – basically with one click you can reformat your CSS layout to go between a long list (properties on multiple lines) or a one line view (everything on one line).
I personally like to edit my CSS with the properties on multiple lines – then when I’m finished I like to shrink everything down – reducing spaces – extra characters etc.
There is also another option that is even better! There are buttons within the program that let you collapse ALL of the CSS properties leaving only the selectors. So all that you see is a list of the all the selectors. Example…
.Item1 {+} .Item2 {+} .Item3 {+} h4 {+} #Excetra{+}
This makes tings super simple – find the selector you want quickly – click on the plus sign to expand the properties and you’re rolling – editing CSS like a fool.
If you’re a CSS guru or just find yourself editing long nasty CSS files – this is definitely a tool to put in the toolbox. And no I have nothing to do with Bradbury or promoting the product – its just way handy.
July 20th, 2007
Thats not a bad idea, it does make things clean. As stated before it really comes down to personal preference. To be honest none of my CSS files every get long enough to where it is a problem, this is because I normally have 6 – 10 CSS files for a website, so I guess you could say I break it down using separate pages. Even still, I think I will try it.
July 21st, 2007
Good post. Im personally more of a traditional CSSer myself. But I understand your plight. For me, I simply cntrl-f and get my ID. I’ve never been much of a fan of single line CSS. Nothing wrong with it though. More power to you. :) Nice blog.
July 21st, 2007
Luckily, I use SASS – means I don’t have to worry about all that, I write it all in an easy to read format similar to YAML; and unlike a normal CSS document, which grows to 300 selectors due to replication, with SASS I can work very DRY – only say everything once, meaning I don’t have to go searching through! It’s all in it’s obvious place, and it’s all easy to maintain and edit. I suggest you give it a try d-:
July 22nd, 2007
In the past I have placed one attribute per line. I continue to code my CSS in this fashion, and after validation go back and place all attributes on a single line. For me it is easier to develop the stylesheet with each attribute in a separate line, but I do prefer the appearance of the single line method.
July 23rd, 2007
I always used to use single line css selectors, but more recently I started using the regular formatting more often. I usually don’t scan my css, preferring to just use the search function
July 24th, 2007
Finally I found someone, that styles CSS the way I do! When I validate with TopStyle, clicking on a reported error brings me right to the attribute that’s causing it (not only to the corresponding line). Since my monitor has a horizontal resolution of 1620 Pixels (in a few days I will even upgrade to 1920), horizontal scrolling usually is not an issue to me. In general I think, the more you can scan with your eyes and the less you have to scroll with your mouse, the faster you can get an overview.
July 25th, 2007
Most editors/IDEs these days allow you to collapse blocks. I know that Visual Studio saves which blocks you collapse/expand, but I don’t usually use Visual Studio for web development (unless of course I’m writing something in ASP.NET) – but maybe that will change when Visual Studio Orcas comes around with its excellent JavaScript intellisense. Whether or not the application saves the current view isn’t all that important for CSS though, since it isn’t quite as necessary as an actual language.
July 27th, 2007
I’ve always found it interesting to examine how people decide to structure their information. Personally, I use the single-line CSS approach and l-l-love it. I’ve found that grouping 5-10 logically similar lines together (e.g. footer navigation) improves the scanability of my CSS. And fear not the whitespace.
Another tricklet is to develop your own ordering for attributes within a declaration and stick with it. This way you have a good idea where to look horizontally for the desired rule. I use this order: { float; display; width; height; margin; padding; border; background; color; font-size; font-weight; }.
I’d like to hear some best practices for multi-page CSS. Or even better, the techniques for mapping a virtual URL structure to physical files. Is it more advisable to store images required by CSS near style.css or with all other images in a subdirectory? What about our PSDs and other source files, do we keep them with the exported versions or group all source files together in a mirrored hierarchy? It’s a troublesome subject to explore, but such comparisons could help people organize and develop their projects more efficiently.
July 28th, 2007
I use SciTE for all my coding needs, it has a useful feature where you can hide all the attributes ( view -> toggle all folds ) making the document shorter. When you need to edit a selector’s attributes you can simple click on the + symbol next to the selector and the attributes unfold.
July 29th, 2007
so… imagine now, that you have over 10 attributes in some selector… your line is being wider and wider… like for example your file http://orderedlist.com/assets/2007/7/12/ol.css -> body
July 29th, 2007
I love being the person who leaves comments and doesn’t have a clue about what you have just posted. Jeffrey and I went to Dayton this weekend to see Michael and Jeannette. While we were there he was filling us in on some of the things you are doing. It was awesome to hear about everything God is doing. I’m excited to see what else happens. I’m praying for you guys.
July 30th, 2007
PSPad (my prefered text editor) has a handy option to convert to and from one line to multiline CSS. I always convert to one line before saving.
July 31st, 2007
Why do not code a java-method on a single-line? because its difficult to change thinks after some months or its difficult if another person want to understand your sourcecode.
The same reason matters for CSS-Code. The Problem is, there is no framework for CSS-Files like eclipse for java where you can open and close, oder or change methods easily. That would be the best solution.
August 1st, 2007
I always find that whilst I am still developing I use the multiple line method simple as I can quickly find attributes and alter them without any trouble.
Once the site is finished however I like to convert them into single lines. I haven’t tested but it is supposed to improve loading times.
August 1st, 2007
Okay, it would be very very cool if there is a tool for switch between both mode :) BTW: Your “WYSWYG” comment-system is really very very great, I like this!
August 2nd, 2007
I never actually thought of it this way, I always just assumed that the single line CSS code was some crazy coding style (like using emacs, :P). Although, it makes a lot of sense, I just prefer the multi-line style. I suppose its easier on my eyes. And finding errors is something I don’t enjoy, so anything to make that easier :P.
August 5th, 2007
I prefer multi-line for organizational purposes when coding by hand, but the best use of the single line selectors method is used by Panic on the Coda app. Hands down.
August 6th, 2007
I have preferred this method for a couple of years now. I remember first seeing it on a previous incarnation of Ryan Sims justwatchthesky.com and I thought it was rather hard to read. Now, I wouldn’t do it any other way, except, as Natalie mentioned, when other people may be maintaining it later on. It is much easier to scan a large file, in my opinion. Besides, I like having all my screen space used more efficiently.
I also like using dashes for a horizontal rule to break things down, which I know adds to the file size, but makes it easier for me to maintain. I think it all comes down to what is easier for you to manage.
August 7th, 2007
When I first started coding CSS I used the one-liner method. Now I use BBEdit or CSSEdit, which, as someone mentioned previously, allows me to collapse selectors and, in CSSEdit, see a visual list of them on the side. I highly recommend it.
August 7th, 2007
I’ve been using the single line CSS for a long time but since I use dremaweaver for editing CSS files It automatically format them to multiple lines and i have to manually collapse them. I am aware of CSSEdit but we don’t have it available for Windows :s
August 8th, 2007
hi there. are there any editors that can automatically format my sheets this way? otherwise it’s quite a job hitting that tab button.
August 9th, 2007