[Partyfists]

Of course! The idea behind using preprocessors is helping you write CSS more easily. The goal is not to write obfuscated CSS, but rather to write CSS well! What it really enables (imo) is to think of styling in an Object Oriented way. Whenever you're about to write a block of Sass think "What is this thing?". The answer is almost never a "green button" but rather "getting started button". Or something like that. It also helps you to think in terms of inheritance:

The "getting started button" and "buy button" are both interaction buttons. (Similar buttons, but one is green and the other is yellow).

In Sass you represent that this way: 1. Placeholder %interaction-button class where you outline the fact that it has a border radius, color, and any other shared styling. 2. A button maker mixin where you put the colors that need to be changed, and any other flags (like has_sub_text: true for the unbold text) and then @extend's the placeholder above. 3. The classes ".buy-button {}" which include the mixin you made.

[MaxGabriel]

To clarify, for the `.buy-button` class, is that where one should put super-specific styles like `margin-left: 12px`?

Also, is there a good place I can learn these kind of things? I'm a programmer trying to get better at CSS (SCSS now that we've setup the asset pipeline)—so far I've been reading random A List Apart and The Sass Way articles, but I feel like I could use a more holistic, in-depth understanding of CSS if there's a good book out there for that.

[Partyfists]

To answer your first question, yes that is exactly where you should put your super-specific styles. You want to put your communal styles in your placeholder, styles that all types have but are different in the mixin (background color, etc) and the rest on the class itself.

The best way to get better at Sass is to follow people who are active in the community (which unfortunately is not me). Start with Chris Coyier and Hampton Catlin and work your way from there.

If you don't mind me plugging my own talks, I have a few that are really good at learning Sass:

https://speakerdeck.com/liamdanger/why-your-sass-is-bad-and-...

https://speakerdeck.com/liamdanger/what-if-css-was-object-or...

https://speakerdeck.com/benbayard/how-to-raise-a-code-puppy

[brickmort]

I appreciate your advice on this! From what I'm learning from you, it sounds like I'm committing some bad CSS practices myself.

[madeofpalk]

I would take a look at BEM. It's methodology and set of naming conventions to help write better, more modular and reusable CSS. It can take a while to get used to, and to get it right, but once you do it's a lifesaver. I can't imagine doing front-end dev without it now

http://csswizardry.com/2013/01/mindbemding-getting-your-head...

http://www.smashingmagazine.com/2012/04/16/a-new-front-end-m...

[karmajunkie]

I'm not a designer by any means, so take this with a grain of salt, but after reading through the first link, BEM bears a striking resemblance to hungarian notation, which I think most of us decided was a bad idea a long time ago. Do you have any sense that this naming convention is different somehow from the naming conventions that have been used and abandoned in other areas of software development, and if so, what makes it different?

[id]

Is it advisable to just use plain old CSS these days?

[Partyfists]

Hey Id,

I'd say learn how CSS works first and really understand what it's doing. However, Sass can help you write very maintainable efficient styled code.

I will always recommend using Sass, but only if you know what CSS you're making and know that it matters what CSS is being output.

[fenier]

In general, you get more out of using a preprocessor.

In practice however, the generated output isn't always the best, and it's worth a look over to make sure it's not generating slower selectors.