

Sass Style Guide - drinchev
http://css-tricks.com/sass-style-guide/

======
kawsper
I am a bit sad that the community seems to prefer Scss over of Sass.

But I really welcome these technologies, because anything that makes CSS more
maintainable is welcome.

~~~
jabbernotty
I thought sass and scss were the same thing.

~~~
jvzr
SCSS still uses {} and ; while SASS goes for Python-like syntax with
indentation doing most of the work. But they are the same thing and are
developed by the same guys.

------
freshyill
Nesting a maximum of three levels deep is _generally_ good practice, but don't
let that stop you from using parent references (&). This doesn't create a
longer CSS selector, even though it's technically nested deeper in the SASS.

In case what I'm saying makes no sense: <http://codepen.io/seraphzz/pen/ByEcx>

~~~
smrtinsert
Nesting should be as long as it needs to be provided the structure is semantic
and not html tags.

~~~
program247365
Yes, but also while keeping in mind best practices, for speed of rendering in
browsers:

[https://developers.google.com/speed/docs/best-
practices/rend...](https://developers.google.com/speed/docs/best-
practices/rendering#UseEfficientCSSSelectors)

See Github's slide deck on CSS performance, and what they gained by being
smart about refactoring, and how they use selectors:

<https://speakerdeck.com/jonrohan/githubs-css-performance>

~~~
smrtinsert
html based diffs might be a special case, but the report is very interesting,
thanks for the link.

------
wincent
Shameless plug: the scss-lint tool we built at Causes provides you with an
automated way of enforcing a consistent style, including a number of details
not mentioned in the original article:

<https://github.com/causes/scss-lint/>

------
bchen
Great list. I agree with most of these conventions, except the following:

> List "Regular" Styles Next

> List @include(s) Next

Depends on what the @include gives you, I would either treat @include the same
as @extend and put @include after @extend, or just treat @include as regular
styles and mix them together. The reason for this is that I generally organize
my styles by listing block styles first and then the text styles. It would
mess up this organization if all @includes that set only 1 property are listed
the last.

------
duiker101
Am I the only one that thinks css-tricks is a really ugly website? which is
kind of ironic...

~~~
mnicole
I love Chris Coyier for everything he's done for the front-end community, but
between his CSS-Tricks layouts and Codepen.io, his aesthetic is much to be
desired.

------
drivingmenuts
I generally tend to go with @extends and @includes first, followed by the
specifics for that rule. Alphabetized, because I'm that OCD about it. So,
externalities first - if you mix them in the middle of regular rules, it's
easy to overlook.

------
tsunamifury
The complexity that SCSS and Sass are demanding seems to point to a need to
abstract design elements of CSS from the complex layout engine its becoming.

Hunting through this to set fonts and colors (the original intent of CSS) is a
bit of a nightmare now. Could we solve this by creating a design only CSS
style sheet that defines the variables that plug into this more complex
system?

This way designers can tweak live code without hunting through long and
difficult to read stylesheets that point to 50?! nested objects.

~~~
crisnoble
Once you use Sass or LESS you realize that it is much much easier to update
things like colors and fonts and font sizes, since they can all become
variables. Update one line of code and all of the rules will change.

The number 50 you refer to is max number of lines of code the autor recommends
inside of a nested rule, specifically so that you don't have to dig to far in
to tweak a rule.

CSS preprocessors were scary to me at first, but I once I started digging in a
bit I realized I could never ever go back.

------
dfischer
Good stuff. I’ve been compiling a list of best practices at
<http://betterfrontend.com> – it’s open source so feel free to add your
feedback.

------
bwilliams
A lot of this was really good but I disagree with three points. You shouldn't
stop using ID's unless you have a reason to. Mixing dashes and underscores is
just ugly. And finally he calls @import after he declares his own styles which
will override anything that he just declared. That is the opposite behavior of
what you want it to do most of the time. Beyond that most of it is a good
write up and has some really good rules that really help keep your SCSS clean
and organized.

~~~
isleyaardvark
>You shouldn't stop using ID's unless you have a reason to.

The opposite approach is more useful: don't start using ID's unless you have a
good reason. Classes can do anything (CSS-wise) that id's can, and lack the
downsides (namely reusability and dealing with increased specificity, here's a
pretty good write up: [http://csswizardry.com/2011/09/when-using-ids-can-be-a-
pain-...](http://csswizardry.com/2011/09/when-using-ids-can-be-a-pain-in-the-
class/))

------
gbog
The one thing I don't agree too much with is splitting in many small files.
This slows down refactoring and long files are handled properly in good
editors.

~~~
program247365
The reasons for this are a couple I can think of:

1\. Large web applications will eventually demand this of you to break the
large solution into smaller chunks (components/modules).

See this methodology: [http://coding.smashingmagazine.com/2012/04/16/a-new-
front-en...](http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-
methodology-bem/)

SASS will help you follow whatever standard/methodology your team may be
following.

2\. And having multiple files will ease development on a large team. Having
multiple frontend developers checking in code, it helps to organize, and
alleviate one developer stepping on another when checking in SASS files into
source control. No conflicts, if developer A is working on the footer, and
developer B is working on the header, which are separate SASS files.

I don't agree that it slows down refactoring, and would argue it speeds it up.
In the end, the multiple SASS files will probably (depending on how you do it,
and your situation), compile down into one file. SASS also has options that
allow you to say what the output looks like too (nested, expanded,
compressed).

~~~
gbog
Dev a working on the header and dev b working on the footer is an ideal case
that actually never occurred to me. Most of the time they work on both. And
any good versioning tool properly used should help avoid conflict, no matter
if the coffee is in the same file or not.

It's not like we are doing c or java under cvs, we don't have to split in
minuscule files, therefore maybe we shouldn't, in python, js, or css dialects.

------
coldpie
I've never heard of Sass before, so I thought this was a standard for how to
communicate sassiness online.

------
camus
Why most people like sass over less?

~~~
jwarren
The language has more powerful functions available, or at least it did when I
first compared them.

I also find Compass, Bourbon and Susy to be great assets.

The Chrome dev tools support is outstanding.

The biggest drawback is that there's no client side evaluation like less.js.
This occasionally makes working with other people a bit tricky. I usually make
a sandbox.css for them to fiddle with, and then incorporate their changes
every so often.

~~~
ceejayoz
> The biggest drawback is that there's no client side evaluation like less.js.

I've seen less.js make its way into live sites enough times that this almost
counts as a positive for Sass for me.

~~~
program247365
For designers, just including a JS file that does the compiling on the fly
seems why LESS gets more love from that group. And also that Twitter Bootstrap
uses it as default (although there are SASS ports of Bootstrap).

For beginners/designers to the whole precompiling CSS scene, setting up Ruby
for the SASS/Compass toolchain could possibly be daunting. Although there are
nice GUI alternatives: [http://mac.appstorm.net/roundups/internet-
roundup/5-mac-apps...](http://mac.appstorm.net/roundups/internet-
roundup/5-mac-apps-that-make-css-preprocessors-easier-to-use/)

However I agree with other comments that it seems there are more
tools/frameworks built on SASS (with Compass), that make it more appealing to
me.

