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.
say you were building an accordion, you might want
.adn {
.adn-header {}
.adn-tab {}
}
instead of the below which is just recreating the dom. This allows you to meaningfully target the elements you want instead of just blindly applying styles everywhere.
SCSS is a lot easier to pick up for new devs, in my experience. "CSS with nesting and variables and some other cool stuff" is significantly easier to grasp.
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.
They are. The names just represent the two different syntax styles that the project offers: traditional brace style (Scss) or Haml-like significant whitespace structure (Sass).
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:
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.
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.
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.
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.
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.
SCSS actually makes this easier, given that you can have partials; it makes it easy to separate out layout and visual style and then combine them into a compressed stylesheet automatically.
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.
>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-...)
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.
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).
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.
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.
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).
Sass supports nested media queries and custom functions. It has extensions like compass, which creates cross-browser supported css with ease. I was used to do everything with LESS two years ago, but recently I needed to switch for SASS, because of that.
In case what I'm saying makes no sense: http://codepen.io/seraphzz/pen/ByEcx