Blog Single

SASS

Sass (which stands for Syntactically Awesome Style Sheets) is an extension to CSS. It doesn't really change what CSS can do, you won't suddenly be able to use Adobe Photoshop blend modes or anything-but it makes writing CSS a whole lot quicker and easier.

Saas includes various features such as variables, nested rules, mixins, inline imports, built-in functions to manipulate color and other values, all with a fully CSS-compatible syntax.

What I do like with Sass is its conservative approach to CSS. Sass’ design is based on strong principles: much of the design approach comes naturally out of the core teams’ beliefs that a) adding extra features has a complexity cost that needs to be justified by usefulness and, b) it should be easy to reason about what a given block of styles is doing by looking at that block alone. Also, Sass has a much sharper attention to detail than other preprocessors. As far as I can tell, the core designers care deeply about supporting every corner-case of CSS compatibility and making sure every general behavior is consistent. In other words, Sass is a software aimed at solving actual issues; helping to provide useful functionality to CSS where CSS falls short.

Preprocessors aside, we should also mention tools like PostCSS and cssnext which have received significant exposure these last few months.

PostCSS is commonly (and incorrectly) referred to as a “postprocessor”. The assumption, combined with the unfortunate name, is that PostCSS parses over CSS that has already been processed by a preprocessor. While it can work this way, it is not a requirement so PostCSS is actually just a “processor”.

It lets you access “tokens” of your stylesheets (like selectors, properties and values), process these with JavaScript to perform some operation of any kind and compile the results to CSS. For example, the popular prefixing library Autoprefixer is built with PostCSS. It parses every rule to see if vendor prefixes are needed by referencing the browser support tool CanIUse and then removes and adds vendor prefixes that are needed.

This is incredibly powerful and great for building libraries that work with any preprocessor (as well as vanilla CSS), but PostCSS isn’t particularly easy to use yet. You have to know a bit of JavaScript to build anything with it, and its API can be confusing at times. While Sass only provides a set of features that are useful to write CSS, PostCSS provides direct access to the CSS AST (abstract syntax tree) and JavaScript.

In short, Sass is somewhat easy and will solve most of your problems. On the other hand, PostCSS can be difficult to take in hand (if you aren’t great with JavaScript) but turns out to be incredibly powerful. There’s no reason why you can’t and shouldn’t use both. In fact, PostCSS offers an official SCSS parser for just this thing.

#2. How Sass Works?

You can't send Sass code directly to the browser; it won't know what to do with it. Instead, you need to use the Sass pre-processor to translate the Sass code into standard CSS, a process known as transpiling. Transpilation is very much like compilation, but instead of translating from human-readable source code to machine-readable object code, it translates from one human-readable language to another, in this case from Sass to CSS. You might be familiar with another transpiler used in web development, Babel (), which translates ES2015 into JavaScript that is compatible with downstream browsers. Different languages, same process.

Don't worry about exactly what's going on during the transpilation process. It's one of the (very few) things in our profession that "just works". All you need to understand is that you give the transpiler some Sass code and you get some CSS code back

Transpiling from Sass to CSS is easy. Consider the following example of Sass code.

    /*define a variable for the primary color*/
$primary : #434433;

/*use the lighten() function to determine the disabled value,
and define it as a variable*/
$disabled: lighten($primary, 20%);

.menu-item {
   color: $primary;

.disabled-menu-item {
   color: $disabled;
}

Saas transpiler will generate the following CSS for the above Sass code.

        .menu-item {
   color: #434433;

.disabled-menu-item {
   color: #76785A;
}
      

As you can see, variables are replaced by values in the CSS. Thus, Sass makes it easy to create and maintain CSS files for your application.

#3. Why a stylegude?

A styleguide is not just a pleasing document to read, picturing an ideal state for your code. It is a key document in a project’s life, describing how and why code should be written. It may look like overkill for small projects, but it helps a lot in keeping the codebase clean, scalable and easily maintainable.

#4. Syntax & Formatting

Strings

Believe it or not, strings play quite a large role in both CSS and Sass ecosystems. Most CSS values are either lengths or identifiers, so it actually is quite crucial to stick to some guidelines when dealing with strings in Sass.

Voluptas dolores dignissimos dolorum temporibus, autem aliquam ducimus at officia adipisci quasi nemo a perspiciatis provident magni laboriosam repudiandae iure iusto commodi debitis e st blanditiis alias laborum sint dolore. Dolores, iure, reprehenderit. Error provident, pariatu r cupiditate soluta doloremque aut ratione. Harum voluptates mollitia illo minus praesentium, rerum ipsa debitis, inventore?