Skip to main content

Writing Cleaner Sass

2018-10-12

One of the main reasons Sass is a clear winner over regular CSS is its ability to reign in the unruly vanilla CSS by providing structure, reducing code repetition and is scalable among other things. Sass among other CSS compilers should be at home in every developer's toolbox and all web developers should be on board.

The problem is, however, simply just using Sass doesn’t instantly make your CSS easier to understand, to some degree perhaps, especially if you’re making the effort to split up site components, pages, regions etc into their own respective directories and files, but more often than not this isn’t good enough. There have been times in the past when first discovering Sass, and also when exploring Sass written by other developers, that it can become quite a nuisance to carry changes over from one part of the site to another, or when wanting to make a change across the board, there are so many instances whereby planning things out and adhering to a style guide, that changes needn’t require modifying or duplicating code all over the place. This article intends to try to encourage some better practices when developing with Sass to keep it cleaner and easier to maintain in the long run, also it is worth noting that this article is based on personal preference and mostly intended for backend developers who occasionally work on the frontend or want to develop their front-end skills more.

Keeping with the program

Chances are a lot of the time if you’re building out, or beginning to build out the theme for your web application, you’re going to be using a framework. For Drupal 7 and 8, one of the most widely used is the Bootstrap framework. The thing about larger frameworks like Bootstrap as opposed to more minimal ones with usually only one small file, is that there’s always the chance during development that you might actually be adding unnecessary extra work, especially when you open up a site that already been built and has a lot of components to the point that you’re staring at multiple directories of Sass files and wondering what can the site already do. Sometimes, however, it’s wise just to take a pause and think before you dive in and start adding styles to a page or new component type. Because chances are you already have things you can readily extend or use, especially if it’s a large site build.

One of the things I do, if I’m working on an existing site, is taking a look at the documentation for the framework the Sass is built upon, usually a components page has the answer because on it will be listed everything from buttons to CTAs or sliders, carousels, tabbable blocks and headings and typefaces etc. On top of this, you can sometimes find useful Sass mixins and classes that are available to the framework. Even if you’re already super familiar with the framework, it can still sometimes be good to make reference to the component page from time to time, especially when it’s a fairly component heavy framework; for instance if you’re using Bootstrap or Foundation then you’ll want to make reference to their API more often than you would a minimal one like Skeleton.

From here the next step should be to start checking your Sass variable, global or colour files, or files that you tend to have in the root of your Sass containing overrides or mixins, because it’s here you’ll usually see the extra components that your team have made, some may be in the past by developers no longer working there anymore, and things like colour variables to help avoid scattering hex and RGBA codes across your files or odd margins, paddings and borders, or adding redundant and new colors, classes or mixins when they may already exist.

Structure

Be aware of the current structure of what you’re working on. It’s quite common to keep your main Sass file at the root of your Sass directories to handle the inclusion of other files and components. Normally here you will also find files containing global variables, framework variable overrides, palettes and colours and mixins. Beneath the root structure should be component, page, region-specific Sass code for keeping things organized. Keeping this structure in mind along with the previous section regarding framework conventions, you should be looking to reference your mixins and variables frequently, especially if you’re trying to keep things consistent across the site. Things like padding, margins, heading sizes and typefaces, colours, button sizes should be kept in one place and administered there, you should try to avoid filling up a file with px margins and paddings, overriding font-sizes and typefaces and adding all sorts of overrides in a Sass file, as this will eventually become a habit and you’ll soon find that numerous pages all are using a slightly uneven set of margins and paddings or sizes, and even if they aren’t, it can wind up being a pain to have to go through and make adjustments and really goes against what Sass is about.

A few examples of thing I find really useful are: Spacing - This means using a class on specific elements and a mixin in your Sass files, you can use a simple integer to denote how much space you want; padding or margin or both. This helps keep the margins and paddings on the site consistent and prevents certain elements looking out of place. Bootstrap 4 now contains this convention, you can read it here: https://getbootstrap.com/docs/4.1/utilities/spacing/Palette - Having a standard colour palette for your site should be very important for keeping things clean and consistent also. By selecting a primary, secondary and in some cases ternary set of colours, you can be sure your links, header colours, text colours, buttons, CTAs, borders all keep to a specific standard, without littering your Sass code with colours. A tool I find very useful for selecting palettes and variables is this: https://coolors.co once you have a palette in place you can list out your colors in a color file labelling them something like $primary1, $primary2, $secondary1, $secondary2 etc. and when you want to make some easier color names you can extend them i.e. $dark-blue: $primary1, $blue: $secondary1, $dark-green: $primary2, $green: $secondary2. Little things like this can make a big difference, especially when you want to swap out a colour sitewide. The point is to keep your colour names consistent with others and make sure they are placed alongside other colours. Text-Shadow, Box-Shadow, Section Rule - Again for standardization's sake, by creating a simple mixin that you can include whenever you want to add any one of these, you’ll prevent redundancy, especially if you suddenly decide you want to change the shade or sizes of these in one spot without having differing values.

One of the main things you should really do is if you want to copy a style from one place to another, maybe with a slight modification, consider turning it into a mixin or a class that you can extend. When you have an awesome set of classes you can use across the site, they become much easier to maintain and if named well, can give insight into what it’s doing when examining the markup.

Style Guide

Along with framework documentation, a style guide serves as an excellent point of reference when working on a site, especially if you’ve never worked on it before, or if you have been away from it for a while.  If you’ve not heard of a style guide before, it’s exactly what it sounds like; it is a page that lists things out like typefaces, header sizes, font sizes, margins, paddings, CTAs, sections, blocks, links, buttons, layouts etc. Basically an itinerary of what you have available currently on the site, but also a standard that should be adhered to throughout development. There are two real ways you can go about it; the first way is to hit up a google search and start looking for some existing examples of style guides, here is a small example of a style guide/and then begin creating your own style guide by hand, and then slowly amending and updating it as you progress through your site build and maintenance.  The alternative, however, and probably quicker and a better alternative when you don’t have time allotted to create a style guide by hand is to use a style guide generator tool like Atomic Docs an excellent site for discovering more tools is Styleguides.io which should assist you in creating your own style guide. For instance, if you’re tasked with creating a flip card, you could check your style guide to see if a card type already exists, if it does, you could extend it and update your style guide at the same time. Another excellent reason for a style guide obviously is if you make a change in one place, you can check the style guide to see if anything else might have been affected, leaving less chance of being told to go and fix something that might have been affected elsewhere.

While this article bears few to no code examples, it is meant to provoke forethought into planning to make life easier in the long run. It’s all too tempting to dive right in and get something done as quickly as possible when being assigned a task, but it only really takes a few minutes to take a breath and reference your documentation. Have something useful you think could be used elsewhere? Make a mix in! Thinking about adding ten lines of code to a new class you’ve added, maybe there’s a mixin or a few mixins available already, or maybe make the class open to that specific element type in general, or perhaps it would be better to break the class up into multiple classes each using a mixin. Most frontend developers will more than likely be thinking about this stuff anyway, however, for backend developers who make the occasional forays into frontend development, start treating Sass like an actual programming language and thinking about structure.