Sass: Tips and tools

Just like how jQuery revolutionized vanilla JavaScript, Sass also revolutionized vanilla CSS . Most developers think that when they use Sass, they no longer want to go back to old tools. Many also agree that the biggest problem of young developers is how they use Sass , not the tool itself.

The article will summarize the best tools and tricks for getting Sass code that can be expanded and reused . The information in the article is taken from the personal opinions of the author and many reputable websites such as Sass Guidelines .

File structure

File organization is the best place to start in Sass programming. If you are interested in modular code, you will probably understand the importance of imports and partials.

But for now, look at the file structure example from DoCSSa first. I recreated this file structure as you see here:

This is just a suggestion for you and one of many ways to organize the file. There are many other methods of using other folder structures such as "globals" for site-wide SCSS and "pages" for page-specific SCSS.

Let's examine the purpose of each folder in the organization style suggested below :

  • / globals – Contains Sass files that apply to sites like typography, colors, and grids
  • / components – Contains Sass file with styles for elements such as buttons, tables, input fields
  • / sections – Contains Sass files for each page or specific area on the page (may work better when combined with / components / folder)
  • / utils – Contains utilities (third party) like Normalize, which can update dynamically with tools like Bower .
  • main.scss – the main Sass file in the root folder, imports all other files.

These are just the most basic points, you can extend more of your own ideas.

No matter which SCSS organization you choose, keep in mind that you will need to update some organizations with a single file (or folder) for libraries like Normalize , along with elements in Sass partials for the project.

Sass partials are extremely crucial for many of today's top programming methods. Sass partials are highly recommended by Zurb's design team and many professional frontend developers are encouraged.

The following is an excerpt from the Sass website explaining partials;

"You can create a partial Sass file that contains many snippet CSS to add other Sass files. This is a great way to modularize CSS and make it easier to maintain. A partial is simply a Sas file whose name begins with an underscore (_). Can be something like _partial.scss . The underscore will help Sass know that this file is only a partial file and should not be generated into a CSS file. Sass partals are used with @import directive. "

Other information about Sass file structure:

Tactical Import

Again, the importance of Sass import and partials is extremely large. The code organization is the key to an efficient import and workflow structure.

The best place to start is with a globals sheet containing imports, variables and mixins. On the syntax side, many developers prefer to separate variables and mixins.

Remember, mixins are import methods, or duplicate Sass code . Extremely powerful mixins should not be used with "static" code. Furthermore, mixins, extends, and placeholders all have their own differences, and all have their own effect in Sass programming.

Mixins show the most significant importance when combining with dynamic values, transferred into mixin to change the code. For example, the following Sass mixin , help create a gradient background between two colors.

Mixin occupies two values: upper and lower colors. You can write multiple mixins for different types of gradients, up to 3 or even 4+ different colors. Thus, you can import and clone mixin code, and also change the parameters for custom options.

Code Responsible example looks like this:

Related to mixin is Sass's placeholder , which is often used with the extend directive . While there are more complex mixins, this is still an effective tool for those who want to combine selectors without writing too much code.

Although Sass has only one @import method, I have added mixins and placeholders to describe the flexibility of code that can be written in a file, but mentioned elsewhere.

When building an import structure, remember to follow the DRY coding concept (Don't Repeat Yourself).

Naming conventions

General rules for naming conventions apply to variables, functions, and mixins. When naming in Sass, you should use full lowercase with a dash to separate.

Sass code syntax in practice based on CSS guidelines set of rules. Here are some recommended standard structures you can apply:

  • Indent by two (2) spaces indents, no tabs
  • Ideally, the line is about 80 characters wide or lower
  • Be careful with whitespace
  • Use comments to explain CSS operations

The above rules are not required, but are valuable links from many veteran programmers, in order to create consistency in the code process .

As for the above convention, you can use the following two constructs: One for the Sass name and the other for the CSS class name. Some developers prefer BEM over Sass. There are no more right or wrong settings than any; they are simply different, with different operating processes.

The problem is that BEM does not fully convert to Sass variables or mixing because they lack the block / element / modifier (BEM) structure. I personally prefer the Sass setting, but you can also try anything from camelCase to build your own structure.

When organizing your variables and mixins, you should divide them by type, and list them in alphabetical order . This arrangement makes editing easier, because you will know what to look for, where to go.

For example, to change the link color, you will have to open the variables file (possibly _variables.scss ) and specify the area for color variables. Then find the link by name (header link, text link, …) and update the color. Simple!

Consider Foundation's settings file .

Another naming scheme involves responsive breakpoints. When placing on Sass breakpoints , try to avoid too specific names for the device. Names like small, med, lg, and xlg are better because they are related.

This is still better for internal links between breakpoints, and is also suitable for teams where developers don't know which devices are interrelated.

When you actually start naming, try to be as specific as possible, and don't touch variables too long . You should apply the same naming rules to the whole site to make it easier to remember when code.

Assign specific naming rules to all criteria like colors, margins, front stacks, and line-heights. Thus, we can not only recall names quickly, but it is also easier to write new variable names that match the existing syntax .

Nesting and Looping

These two Sass techniques are very difficult to apply in practice. However, both are at risk of abuse if we are reckless .

Nesting is the process of adding nested selectors through indentation to create more specificity with less code. Sass has a nesting guide, illustrating many examples of code nesting in practice. But notice, it's easy to be tempted by code nesting, and give the following code:

Particularly excessive and almost impossible to overwrite, this type of code completely erases the purpose of classifying stylesheets.

Looking through this tutorial on SitePoint , you will see three golden rules in nesting (integrated):

  • Never exceed the depth of 3 layers.
  • Make sure CSS output is clear and reusable.
  • Using nesting is reasonable, not "default", anytime, anywhere.

Developer Josh Broton believes that the general syntax rule is to nest only when needed, and the rest is indent .

Indenting selectors will not cause any cascading CSS consequences. But you will be "easier" to surf through the Sass file to determine which class is related to each other.

Loops can also be abused if not applied properly . The three Sass loops are @for , @while , and @each . I will not go over the details of their working principles, but if you are curious, read more here .

Instead, I will discuss the purpose of these loops and how they run in Sass. These loops will help save time for writing code that can be automated. For example, here is an example from the Clubmate post, showing some Sass code, followed by output:

These column classes can be used in conjunction with a grid system. You can even add or remove columns by editing the loop code.

A loop should not be used to duplicate selectors or properties for a selector ; that is the task of mixin.

Moreover, when iterating, we have Sass maps to store key: value pairs of data. Advanced users should try to use these maps as much as possible.

At the same time, the usual Sass loop itself is also a method of providing code output (without repetition) which is very simple and effective . The best reason to use a loop is with CSS properties that transforms data output.

Here is a good way to check if the loop is effective: see if there is any other way to output the CSS you need (with less code) . Otherwise, this loop room structure is good.

Modularization (Modification)

Modular Sass writing practices are extremely important in most projects. Modularization is the process of dividing a project into many smaller modules . In Sass, you can implement modulization with partials .

The idea behind modular Sass is to write specific, purpose-specific SCSS files, targeting global content (typography, grids) or page element (tabs, forms).

The Sass module definition is quite obvious and says one thing: importing modules never has output code.

Required output ideas for all modules become a nightmare when optimized. Instead, you should create individual modules and just call the modules you need . Modules can be defined by mixin or functions, but you can also create modules that contain selectors.

Learn more about Sass modules and modular techniques:

Find your own rhythm

Each team or individual developer has their own way of working with them. Your friends should also find their own way.

In terms of automation and minimizing Gulp and Grunt work are the two most prominent tools today besides many other extremely handy automated tools .

ITZone via hongkiat

Share the news now