It’s only a few months down the road since we have released the redesign of CurrencyFair and with it came a lot of considerations on how to make it responsive and improve the front-end development of the site. One thing we pushed for was to use SASS and we wanted to share how we are using it by sharing a few examples.
Why we choose SASS?
The simple reason is that documentation and examples are much more accessible and extensive than with other preprocessors such as LESS or Stylus and on top of it all, it has a big community of people using it sharing ideas and tricks. As of now we are using SASS at a basic and organisational level mostly, and we are still considering how far we can push its capabilities without overdoing it.
Compiling SASS
There are a few tools out there you can use to compile your SASS (or SCSS, which is the syntax we are using). The one we picked is Koala out of a few because it works great and it is open source. There are other open source apps we are aware of such as Scout and a few other options that are a mixture paid and open source: CodeKit, Hammer, Mixture, etc. which are great and offer pretty much the same compiling benefits. You can compile also using the command line and installing it on your machine, but that’s not how we wanted it and won’t be covered on our examples.
Getting dirty with SASS
We have created specific files i.e., general.scss, colors.scss and typography.scss, used for common mixins, variables, colours or general styling rules that we will load on the main site style i.e., main.scss. Working this way help us compartmentalise the styles according to the specific styling we need to work on. You can do this as well on plain CSS, but the difference is that when you do it only with CSS you are doing an http request for each of those imported files, whereas with SASS you compile all those imported files into the main compiled CSS which in our case will end up being main.css. Here is how it goes:
@import 'general';
@import 'colors';
@import 'typography';
For example, we use ‘Calibri’ as our main font on the site, so for typography we have created this variable:
$calibri: 'Calibri', Arial, Helvetica, sans-serif;
and we call it on the main .scss file with:
font-family: $calibri;
Another example is using our main brand colours:
$darkblue: #396172;
$lightblue: #eef2f3;
$orange: #f15925;
We reference them on the main .scss file as:
background: $lightblue;
colour: $lightblue;
Another example that requires a fair amount of repetitive lines is borders-radius which is a common property we are using for all of our buttons and a few other elements. Another is background-size for our hero images. Because of all the different browser vendors you need to use in these scenarios browsers specific prefixes such as -webkit, -moz, -ms, -o. If you were using plain CSS you would need to write repetitive lines for each browser. With SASS you would go to your general.scss and create:
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
-o-border-radius: $radius;
border-radius: $radius;
}
And to call it on the respective file you’d use:
.calculator-table {
@include border-radius(3px);
overflow: hidden;
}
Compiling this on the CSS:
.calculator-table {
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
-ms-border-radius: 3px;
-o-border-radius: 3px;
border-radius: 3px;
overflow:hidden;
}
For instance for some linear gradients we are going about this with:
@mixin linear-gradient($default, $top, $bottom) {
background: $default;
background: -moz-linear-gradient(top, $top 0%, $bottom 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,$top), color-stop(100%,$bottom));
background: -webkit-linear-gradient(top, $top 0%, $bottom 100%);
background: -o-linear-gradient(top, $top 0%, $bottom 100%);
background: -ms-linear-gradient(top, $top 0%, $bottom 100%);
background: linear-gradient(to bottom, $top 0%, $bottom 100%);
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='$top', endColorstr='$bottom',GradientType=0 );
}
and using it as the SASS file:
.hero-section {
@include linear-gradient(#f3f5f6, #f3f5f6, #e5ecf0);
}
Compiling this on the CSS:
.hero-section {
background: #f3f5f6;
background: -moz-linear-gradient(top, #f3f5f6 0%, #e5ecf0 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #f3f5f6), color-stop(100%, #e5ecf0));
background: -webkit-linear-gradient(top, #f3f5f6 0%, #e5ecf0 100%);
background: -o-linear-gradient(top, #f3f5f6 0%, #e5ecf0 100%);
background: -ms-linear-gradient(top, #f3f5f6 0%, #e5ecf0 100%);
background: linear-gradient(to bottom, #f3f5f6 0%, #e5ecf0 100%);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#f3f5f6', endColorstr='#e5ecf0',GradientType=0 );
}
You get the idea here by looking at these examples, how many lines of code you would be saving on your .scss file. We use similar approach for IE related properties such as the display:inline-block to name a few, which doesn’t work on older browsers such as IE7 and we still need to support—for the time being—based on some of our customers still using this older version..
Now, one of the things that we like the most is the way to organise the selectors. The fact that you can style something that you are used to doing like this:
.pricing-page {
background: #183744 url(../imgs/hero-background.jpg) 100% 0 no-repeat;
-webkit-background-size: 100% 100%;
background-size: 100% 100%;
-webkit-background-size: cover;
-moz-background-size: cover;
-o-background-size: cover;
background-size: cover;
}
.pricing-page .calculator-table, .pricing-page .c-table {
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
-ms-border-radius: 3px;
-o-border-radius: 3px;
border-radius: 3px;
overflow: hidden;
}
.pricing-page .inside-pricing-page {
color: white;
}
.pricing-page .inside-pricing-page h3 {
text-align: center;
padding: 40px 0;
}
To this cleaner code:
.pricing-page {
background: #183744 url(../imgs/hero-background.jpg) 100% 0 no-repeat;
@include background-size(100%, 100%);
@include background-cover();
.calculator-table, .c-table {
@include border-radius(3px);
overflow: hidden;
}
.inside-pricing-page {
color:white;
h3 {
text-align: center;
padding:40px 0;
}
}
}
It makes a huge difference to see how your CSS is structured.
There are a ton more features that we are not using SASS for. Some of these include functions that are almost intertwining with javascript and whether that’s a good thing or not regarding the separation of the 3 layers of the web—behaviour, structure & presentation—we feel that when using SASS, as with any powerful tool, it comes with a great deal of responsibility on how far you can take it. We will be sharing more as we learn and find more useful things to do with it.
Conclusion
We found that by using SASS we can be more conscious about the structure of our CSS and help maintain it better. The style of syntax not only makes it more understandable to see how the main container elements serve as a main styling hook, but also, to see clearly which elements inside that main container are being styled. Besides these advantages, it also helps developers who aren’t used to working with CSS on a regular basis to have a better idea of how things are organised in a more coder-friendly way as well.
Some things that we have heard here and there being mentioned, and that we would like to play around with are Livereload or Codekit for refreshing changes instantly on the browser as we think this might improve productivity. We’ll see how this pans out. Until then, let us know what you guys think or if there’s anything you would recommend we should be doing better :)