This material was originally published on Codica Blog, as part of the article The Power of CSS Processors in Web Applications Development.
CSS Pre-processors have long ago become essential front-end development tools. Fitted with advanced features, they help programmers write readable code. The most common pre-processors are Sass, Less, and Stylus.
At Codica, we believe that these tools can simplify your code and increase your productivity. We want to show their power based on the examples from our practice.
What is Sass?
Let’s start with Sass definition. We can find it on the official website of this CSS extension.
Sass is a stylesheet language that’s compiled to CSS. It allows you to use variables, nested rules, mixins, functions, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized and makes it easy to share design within and across projects.
How to use Sass Mixins, Maps and Loops
Now we will take a look at loops and map functions. With these remarkable and rare tools, we can embrace all the power of CSS.
We know SCSS as an extension of CSS syntax. At Codica we often use it for developing web projects. It is closer to native CSS and does not require extra operations when you copy your code from a browser.
On the code snippet below you can see how Web Fonts are declared in CSS. This example clearly shows code duplication in style sheets.
@font-face {
font-family: 'OpenSans-Light';
src: url('opensans-light.eot');
src: url('opensans-light.eot?#iefix') format('embedded-opentype'),
url('opensans-light.woff2') format('woff2'),
url('opensans-light.woff') format('woff'),
url('opensans-light.ttf') format('truetype'),
url('opensans-light.svg') format('svg');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'OpenSans-Regular';
src: url('opensans-regular.eot');
src: url('opensans-regular.eot?#iefix') format('embedded-opentype'),
url('opensans-regular.woff2') format('woff2'),
url('opensans-regular.woff') format('woff'),
url('opensans-regular.ttf') format('truetype'),
url('opensans-regular.svg') format('svg');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'OpenSans-Bold';
src: url('opensans-bold.eot');
src: url('opensans-bold.eot?#iefix') format('embedded-opentype'),
url('opensans-bold.woff2') format('woff2'),
url('opensans-bold.woff') format('woff'),
url('opensans-bold.ttf') format('truetype'),
url('opensans-bold.svg') format('svg');
font-weight: normal;
font-style: normal;
}
When you look at this code snippet, you may feel like you are viewing duplicate code.
The fans of the Matrix will remember the scene when Neo sees a black cat walking by and then another one behaving the same way. This moment was a clear illustration of déjà vu during the Hotel Ambush.
Luckily we can easily fix the duplicate code issue with the help of Sass components called map functions and mixins.
Let’s find out how the mentioned tools can help you simplify your code.
In the beginning, we will describe our fonts in map fonts. This process looks as follows:
/* Fonts map format
$fonts: (
$file-name: '$font-name'
)
*/
$fonts: (
opensans-light: 'OpenSans-Light',
opensans-regular: 'OpenSans-Regular',
opensans-bold: 'OpenSans-Bold',
);
Next off, we will use map-get function to declare variables font:
$ff_light: map-get($fonts, opensans-light);
$ff_regular: map-get($fonts, opensans-regular);
$ff_bold: map-get($fonts, opensans-bold);
With the feature @mixin we can prevent the code repetition:
@mixin font-face($font-name, $file-name) {
/* '/assets/fonts/' - relative path to the fonts folder */
$filepath: '../assets/fonts/' + $file-name;
@font-face {
font-family: #{$font-name};
src: url($filepath+'.eot');
src: url($filepath+'.eot?#iefix') format('embedded-opentype'),
url($filepath+'.woff2') format('woff2'),
url($filepath+'.woff') format('woff'),
url($filepath+'.ttf') format('truetype'),
url($filepath+'.svg') format('svg');
font-weight: normal;
font-style: normal;
}
}
After that iterator @each and @mixin mentioned above will help you declare font-face for each font:
/* Font face declaring */
@each $file-name, $font-name in $fonts {
@include font-face($font-name, $file-name);
}
Now if you want to add or delete a new font, you need to upload or delete font files lying in the path which was previously declared in variable $filepath ('../assets/fonts/' in the example). Don't forget to follow ile naming, declared in map $fonts and declare or delete variable:
$fonts: (
opensans-light: 'OpenSans-Light',
opensans-regular: 'OpenSans-Regular',
opensans-semibold: 'OpenSans-Semibold',
opensans-bold: 'OpenSans-Bold',
);
$ff_light: map-get($fonts, opensans-light);
$ff_regular: map-get($fonts, opensans-regular);
$ff_semibold: map-get($fonts, opensans-semibold);
$ff_bold: map-get($fonts, opensans-bold);
Conclusion
In this post, we focused on the features and tools making CSS the core part of your project stylization.
CSS pre-processors, including Sass, enable front-end developers to write clean, efficient, and what is more important, easily maintained code. For most complex web projects easy maintenance is the most basic requirement.
Stay tuned and read about PostCSS: A tool for transforming CSS with JavaScript.
Or, read our full article: The Power of CSS Processors in Web Applications Development.
Top comments (4)
The issue with sass is for compiling scss to css weird non-javascript precompiled binaries are installed in your node_modules, from weird locations. What sass can do, less can do the same, but much safer as it's compiler is a js compiler.
Hi there!
Thank you for your comment. As you correctly observed, at first sight, Sass and Less have almost identical functionality. For example, they both can be used for compiling SCSS to CSS. However, the difference between them is bigger than you think. There are cases when Sass is a clear winner. For example, Sass has more robust libraries. Chris Coyer agrees with this point of view, saying in his article that “the language of LESS itself doesn't make it possible to build as robust of libraries on top of it”. Besides, in terms of language ability, Sass is definitely better than its counterpart. It has actual logical and looping operators in the language that is unavailable in Less.
I hope my comment answers your question.
SASS used until recently JavaScript for it's compiling and now it uses Dart which they claim faster.
Am I the only one bothered about the
font-weight: normaleverywhere in that @fontface? This is probably the most useless way to define custom fonts.