Sass Style Guide | Hacker News Reader

Sass Style Guide

css-tricks.com

98 pointsdrinchev40 comments

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.

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.

I have a really hard time keeping myself from typing the {, } and ; when I'm in "css mode". Instead of fighting it I just embrace it.

I thought sass and scss were the same thing.

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).

Significant whitespace is evil.

Noisy brackets are evil as well :-)

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

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

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

https://developers.google.com/speed/docs/best-practices/rend...

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

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

Not sure to get what you mean. Could you explain a bit more?

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.

div { a {} div {} }

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/

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.

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

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.

That is not ironic or relevant. Don't look at acid tests for aesthetic value. You gotta lighten up...

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.

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.

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.

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...

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.

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

Why most people like sass over less?

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.

> 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.

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...

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.

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.

I use it primarily because I like the tab-indented syntax. I seem to be in the minority with that, but I've never liked CSS syntax.

SASS can also take a bunch of PNGs and auto generate a sprite map and it's CSS.

Sass can't do that, but the Compass framework (built on Sass) has sprite generation.

Less is not always better ;-)

It's the default in Rails, which gives it a large built-in userbase.

Reply on news.ycombinator.com