It was time to dust off CSS and make it more efficient. Nixa has taken a look at SASS and its major assets.
Limits of CSS
CSS is a language that couldn't be simpler. Simple to write, read, modify and reuse. But the limits of CSS arise as the complexity of a project grows. The richer and more dynamic the project becomes, the harder it is to keep style sheets clean, and above all, easily modifiable and flexible. Every web developer has been there... tedious searches, in ultra-repetitive code, for a piece of CSS in order to copy and paste it, add a selector and finally modify it.
So, from the disconcerting simplicity of CSS comes its main weakness: its lack of dynamism.
A new, more flexible and dynamic syntax, replacing CSS, could have been a way of solving this thorny problem, but there are two reasons for this:
- Browsers are not ready to adopt a new syntax for obvious compatibility reasons. And even if they were, full support by all browsers would take several years.
- Despite the handicap it generates, the simple, accessible structure of CSS must endure to ensure that websites can be updated quickly and easily, and are accessible to the uninitiated.
Indeed, the aim is not to complicate a simple practice and process of web site creation (HTML/CSS), but to offer web developers more advanced development tools. This is why the solution was not to replace CSS, but rather to automate and energize its editing: welcome to the magical world of SASS.
Syntactically Awesome Style Sheets
Created by Hampton Catlin and Nathan Weizenbaum, SASS (.sass) allows you to manage style sheets dynamically, using variables, conditions, functions, loops and expressions.
Early versions of SASS were a radical departure from familiar CSS. There were no braces, and strict indentation made it unattractive for developers/web designers to learn. Only programmers, who found familiar systematizations in SASS, looked favorably on this rigor.
The biggest problem with these early versions of SASS was its syntax incompatibility with CSS. In other words, it was impossible to write CSS in SASS style sheets. Imagine the time spent converting a piece of CSS into SASS in order to integrate it into a project...
So, in order to open up to a wider audience and make SASS compatible with CSS, SASS 3.0 introduces SCSS (.scss), which stands for Sassy SASS (the Classy Sass).
Unlike the original SASS, SCSS is much closer to CSS. In fact, it's perfectly possible for SCSS and CSS to coexist in the same style sheet. What's valid in CSS is valid in SCSS. This essential point has made it much easier to win over CSS-savvy web developers who didn't want to take on a language that was far too complex.
Using SASS has therefore become an essential asset in website development, without weighing it down by having to learn complex syntax. On the contrary, SASS has simply enabled developers to finally do what they've always dreamed of doing in CSS, without distancing them from this basic language.
Whatʼs cool about SASS?
We won't get too technical here. Let's just say that SASS is coded in Ruby, and you'll find all the information you need to install it on the official websites. SASS requires a compiler that will automatically transform your SASS into CSS each time you save your file, thanks to an input folder (containing the SASS) and an output folder (containing the converted CSS). There are several ways of implementing this compiler, but we won't go into that here.
Instead, let's take a look at the life-changing features of SASS!
Partials (or how to organize and structure your style sheets simply!)
The use of multiple CSS style sheets in an attempt to structure and clarify files that are often long and indigestible, has never been a widespread method in the sense that each style sheet called up makes a request on the server and therefore slows down page loading. The solution to this problem lies in SASS, which uses partial files containing pieces of SCSS that can be called within a main style sheet, thus reducing requests to that single style sheet.
These partials begin with an underscore ( _ ) to indicate to the compiler that these files are only partials and do not require CSS compilation. This is all done, of course, when the file in which they are called is compiled. They are then called up by @import at the desired location in any main style sheet.
Each aspect of the project can thus have its own independent style sheet (colors, pages, fonts, general structure or responsive).
With this clear, precise structure in mind, it's common to see a "main.css" style sheet made up entirely of partial imports, making the overall structure of SASS files easy to modify and much easier to read.
Variables (or how to stop copying and pasting the same color code 150 times!)
Variables are an essential part of SASS. They enable you to define property values so that you can reuse them without difficulty and, above all, modify them in a single place in the code.
SASS
$font-stack: Helvetica, sans-serif; $primary-color: #333; body { font: 100% $font-stack; color: $primary-color; }
CSS
body { font: 100% Helvetica, sans-serif; color: #333; }
The change in values therefore becomes global and incredibly effective.
Lʼindentation (or how to stop repeating yourself 1,000 times!)
SASS indentation eliminates the need to repeat a path to a selector. Simply integrate the selector directly into the parent selector's braces.
SASS
nav { ul { margin: 0; padding: 0; list-style: none; } li { display: inline-block; } a { display: block; padding: 6px 12px; text-decoration: none; } }
CSS
nav ul { margin: 0; padding: 0; list-style: none; } nav li { display: inline-block; } nav a { display: block; padding: 6px 12px; text-decoration: none; }
So to reach, modify or add a selector at a specific point, it is no longer necessary to copy and paste the path, but simply to integrate it at the desired location. This makes reading style sheets clearer and more intuitive.
Mixins (or how to create declarations that can be reused ad infinitum!)
Mixins allow you to create sets of rules that apply to different selectors. This can be extremely useful, especially for writing essential prefixes for certain new CSS3 features.
SASS
@mixin border-radius($radius) { -webkit-border-radius: $radius; -moz-border-radius: $radius; -ms-border-radius: $radius; border-radius: $radius; } .box { @include border-radius(10px); }
CSS
.box { -webkit-border-radius: 10px; -moz-border-radius: 10px; -ms-border-radius: 10px; border-radius: 10px; }
With a simple @include, a set of rules can therefore be reused very easily. At the start of the project, it is therefore possible to create these sets of rules that we know are recurrent from one project to another and thus use them quickly.
So these are the main lines of the SASS which saves precious time in the creation of a website. Using SASS and a project starter that includes the most commonly used partials, mixins, and variables can save a lot of time and make integration work easier.
The time saving and learning curve of SASS (incredibly fast growing for developers already comfortable with CSS) makes it an indispensable tool now.
Conclusion
For the sake of efficiency and speed of execution, SASS is essential for Nixa. Adopting this development tool allows us to optimize our working time and thus make our processes more efficient!
And since we like to have fun at Nixa, we couldn't miss this new toy! ;)