process.css

/*
This is a pretty crappy brief to tout the benefits of "good CSS", "good SASS", 
"good OOCSS" or anything else, but let's roll with it for now.
*/

#Nav {height:45px;background:transparent}
#Nav ul {list-style:none;margin:10px 0 0 7px}
#Nav ul li {display:inline}
#Nav ul li a {list-style-type:none;display:inline-block;padding:10px 20px;color:#a1a1a1;background:#f4f4f4;border:1px solid #d1d1d1;text-transform:uppercase;-moz-border-radius:4px;-webkit-border-radius:4px;-moz-box-shadow:0 1px 3px #f1f1f1;-webkit-box-shadow:0 1px 3px #f1f1f1}


/*
SASS does lots of cool stuff I really dig, but railsjedi was focusing SASS's 
ability to DRY up the selectors, so let's get rid of the styles themselves 
(that's a whole other discussion) and focus on the relevant bit:
*/

#Nav {...}
#Nav ul {...}
#Nav ul li {...}
#Nav ul li a {...}


/*
SASS is really good at fighting the repetition of these deep selectors, but I 
feel like that's an answer to a question I wasn't asking. I used to think these 
deep selectors were "best practice" for predictability in a complex CSS 
architecture, but I no longer do. In practice, this will probably suffice, 
and negates a lot of the repetition that SASS can DRY up:
*/

#Nav {...}
#Nav ul {...}
#Nav li {...}
#Nav a {...}


/*
Not so bad, eh? Next, most OO-CSS I see encourages the use of classes only,
which allows for re-use and helps avoid specificity wars, so let's make a 
tiny switch:
*/

.nav {...}
.nav ul {...}
.nav li {...}
.nav a {...}


/*
While this isn't a perfect example to roll with, the next thing I'd do is
think about the granularity, trying to build up CSS objects that aren't
dependent on their location in the document so much (or even the mark-up 
choices).
*/

.nav {...}
.tabs {...}
.tab {...}
.tab a {...}

In the model you're suggesting, you'd have to either nest too many presentation elements, or chain several classes together to get the desired effect for a navigation block. That's hardly a better approach. With the approach above, yes, there's a little more CSS, but the presentation layer is simply

and you follow with your structure and I don't have to put classes on subsequent HTML elements. I'm targeting DOM elements instead. I'd rather use fewer custom classes and have CSS leverage the power of the DOM to do things.

All in all, the approach I'm taking requires creating fewer CSS classes and doesn't require you to apply as many CSS classes either chained in the DOM, or to multiple items in the DOM. I'm balancing CSS with HTML/DOM elements.

Now, if we move to HTML5, then it's even simpler:
nav a {...}

No custom CSS classes or IDs and no need to add multiple classes to multiple items in the DOM.

I have lots of CSS in lots of apps that looks a whole lot like your s, I'm actually not trying to slam it. The real point I'm trying to make is that SASS isn't the only answer to the "repetition" found in many stylesheets.

You're absolutely right, I'd be adding more classes to the object in the DOM, but that's exactly what OOCSS advocates, and also what I've found works best for me in the apps I'm working on. My goal is more independent objects that can be safely altered across 100k+ pages in varying layouts and contexts without fear. The trade off I choose (not always, but more often than not), is more classes that do less things in more contexts, because I've found this allows me to iterate faster on a live app in a big team in which I'm the only designer.

Your mileage will vary, and I'm all for that, and a 4 line example is not reflective of a whole app, a whole stylesheet, workflows, the shape of the team, the business demands, etc.

If I make only one point stick, I hope it's this: SASS isn't the only way to write maintainable CSS.

We discussed going LESS vs. OO CSS a few months back. We were in the process of refactoring the CSS and HTML for an app we'd been working on. I had noticed a mix of LESS and OO CSS. I brought up the notion of picking one direction: either LESS or OO CSS, but not mixing the two and wanted our team to weigh the pros/cons of that approach. We walked through real situations in our app, real code to discuss the approach and the impact it would have.

What we discovered was that going straight LESS or straight OO CSS would be a mistake. There are times when using a LESS or DRY approach works best and other cases where OO works best. So, our decision was that going LESS or OO just for the sake of picking a direction isn't the right choice. The right choice is to use the method that makes the most sense and is best given the context. So, for us, we mix OO and LESS. We use LESS when it makes the most sense and ultimately ends up with less code for us to write and maintain in both CSS and HTML and OO when that makes the most sense. In our CSS, you'll find that mix.

We're less about being dogmatic and more about being pragmatic and practical.

No argument from me whatsoever.

Todd and Justin, nothing prevents you from writing Sass that is not deeply nested as you describe. A good rule of thumb is that when you get beyond 2-3 levels you are probably getting too deep.

Yes, you can write bad Sass. Perhaps it's easier to write bad Sass than CSS. But that's probably more of a function of power than anything else. It's much easier to cut your finger off with a skill saw vs. a hack saw. But that doesn't mean that the skill saw is bad. It means that you need to take precautions to use it safely.

Using CSS well requires wisdom. Using Sass well requires wisdom, too.

Where Sass really shines is in code reuse. Features like variables and mixins make it much easier to share code across projects. And if you chose to use Compass, you'll find that letting Compass worry about how to do things like clearfix, and border-radius free your mind up to create not just worry about cross-browser compatibility. You'll type less and enjoy your work more.

Yeah, variables and mixins are really interesting. What I'd like to see is those adopted by CSS straight up—CSS4. That way we can get rid of the compiler layer. Now, that would be awesome.

Quick question, can you write SASS single line? I get that the indents have specific meaning for nesting, but all the examples I've seen so far are individual line vs. single line.

As of Sass 3 you can write SCSS which is SASS with the traditional CSS syntax. In fact CSS files are SCSS files. So yes, you can write it all on one line if you like.

This is an old post referencing the beta, but SCSS is now a feature of the current stable release: http://nex-3.com/posts/96-scss-sass-is-a-css-extension

Sweet.

Compiling has a number of advantages:

1. Sass can explore features that CSS doesn't currently support so the language can continue to evolve reguardless of the implementation
2. Compiled stylesheets can be compressed
3. Syntax errors surface during compilation -- not in the final product like CSS
4. Compilation ensures that the CSS generated will be valid across all browsers. Imagine a world where WebKit and Firefox supported variables, but IE did not. What a nightmare.
5. In the future Sass will probably be able to optimize output. If this follows the trend of "programming" languages, optimized output will ultimately be better than hand coded output.

Oh, and I totally agree about variables and mixins in CSS4. But why wait? Sass allows us to explore possible implementations for these features without limiting us to what browsers currently support.