Last summer, we at Fuga Cloud started rethinking the way we approach writing our CSS. Before this point, we were still using vanilla CSS. This was starting to become more of a problem with every feature we rolled out. So when I started working here, my first assignment was to implement SCSS following the ITCSS methodology. This enabled us to do two things:
- SCSS enabled us to write SCSS in a component-like way
- ITCSS forced us to write our CSS in a logical order
We chose Gulp to compile our SCSS and to automate some other stuff such as minification and sourcemaps etc.
ITSaywhat?
ITCSS is a CSS methodology for building large-scale CSS projects. It presents CSS as a layered upside-down triangle. ITCSS stands for ‘Inverted Triangle CSS’. ITCSS counters some troublesome aspects of CSS like leaking styles and the specificity model.
The reason we chose ITCSS
Because we used vanilla CSS in our projects, we suffered from the fact that the stylesheets our developers had to work with were humongously large. Therefore, a lot of the time rules were declared somewhere in the stylesheet and way down these rules were overwritten again by another developer. This is a problem a lot of companies with development teams suffer from.
Because ITCSS enforces a componentized UI architecture, it forces us to write our CSS in a logical order which prevents overwrites and specificity wars between rules.
Fuga style SCSS
SCSS enables us to write SCSS in a component-like way so every component can be put in it’s own file which can be imported in the main CSS-file. This way, the styles for certain parts of the CSS are clearly separated which in turn reduces the chance of overwritten CSS rules. We use the BEM methodology to ensure that every part of a component can be accessed through a single class, reducing the chance of specificity issues.
Variables
I wanted to handle our variables in a smart and elegant way, meaning that I did not want to use variables like $red throughout the SCSS-partials. This is because, in the future, should we decide that the color of these elements should be another color, we don’t have to pick between two evils:
Either changing the hex-value of the $red variable, leaving you with every instance of $red being anything but actual red. Or the lesser evil, having to rename every instance of $red to something else throughout the project.
Both ‘options’ are unacceptable to me because I’d rather have a semantic variable name describing the function of the variable. I did the following in my /settings/_colors.scss file:
$c-gray: #cccccc;
$c-darkgray: #999999;
$c-border: $c-gray;
$c-bodytext: $c-darkgray;
Then in some SCSS-partial I was able to do something like this:
.some-element {
border: 1px solid $c-border;
color: $c-bodytext;
}
This way, when we decide to change the color for the borders, we ony have to edit the /settings/_colors.scss file and set the c-border variable to something else. You might have noticed the use of the c- prefix of my color variables, I do this so I can always immediately see that the variable is a color.
I also found an NPM module named gulp-sass-json which you can feed an SCSS-partial (the /settings/_colors.scss file). During every build, the task adds all color variables to a JSON object so we can use those same color variables in our JavaScript.
The same principle is used for naming other variables like border-radii. Rather than $border-radius-3 we use $border-radius-small because then it’s easier to update this variable to, say 4px without having to edit all instances of $border-radius-3 throughout the entire project.
Minor deviation of ITCSS
During this refactoring project I chose for a minor deviation of the ITCSS methodology. Instead of 7 layers, we chose to use 8 layers of CSS. The eighth layer being the top layer, named ‘vendors’. Here we put vendor styles like Bootstrap, FontAwesome etc. making it easy to overwrite these styles.
A peek into the Gulp tasks for SCSS
For compiling SCSS we have two tasks, one for development and one for production.
In the task for development we do the following
- Compile the SCSS to CSS
- Add sourcemaps for easy debugging, so we can easily find the SCSS-partial where the actual CSS rules reside
- Add Autoprefixer to add vendor prefixes to the output CSS
gulp.task('dev-scss', () => {
gulp.src(SRC_PATHS.allscss)
.pipe(plumber(errorMsg))
.pipe(sourcemaps.init())
.pipe(sass())
.pipe(sourcemaps.write())
.pipe(postcss(postProcessors))
.pipe(gulp.dest(DEST_PATHS.css));
});
In the task for production we do the following
- Compile the SCSS to CSS
- Add Autoprefixer to add vendor prefixes to the output CSS
- Minify our output CSS
gulp.task('build-scss', () => {
gulp.src(SRC_PATHS.allscss)
.pipe(plumber(errorMsg))
.pipe(sass())
.pipe(postcss(postProcessors))
.pipe(cleanCSS())
.pipe(gulp.dest(DEST_PATHS.css));
});
Alongside that, we implemented some copy-tasks which for example make sure that SCSS vendor-files (or fonts etc.) are copied from the node_modules folder to the src folder. Some teams choose to directly import these files from node_modules in their importer-file. I personally dislike this because I don’t want to commit the node_modules folder to the Git repository but do want to commit these vendor-files so we maintain some form of control over our dependencies.
For example, out Bootstrap copy-task looks like the following:
gulp.task('copy-bootstrap-scss', () => {
gulp.src([
'node_modules/bootstrap-sass/assets/stylesheets/bootstrap/**/*/*.*'
])
.pipe(gulp.dest('assets/src/scss/vendors/bootstrap'));
});
The next step is that we are currently defining our custom components in a styleguide which is set up to closely guard the Fuga Cloud branding and make sure that these components are implemented consistenly throughout our projects.
This concludes this article, I hope you have enjoyed reading it and hopefully found it useful for your next project.
Proudly made in The Netherlands