SASS helps us move away from behemoth styles.css files with many thousands of lines by allowing us to split code up into it’s component files, without adding extra http requests, with the use of SASS partials and @import.
However, splitting our styling into multiple files (partials) on it’s own doesn’t make things easy to find. That’s why we like to setup a particular folder structure, so we know where to look for a particular piece of code.
// src/sass cascade/ components/ main.scss
We try to keep our folder structure as simple as possible, to avoid any agonising decisions over where to save something. We have 2 folders that all your code should go into (
main.scss being the glue that holds it all together.
// main.scss // Init Cascade @import 'cascade/reset'; @import 'cascade/colours'; @import 'cascade/type'; // ..etc // Crowd Carousel @import '../../bower_components/crowd-carousel/src/sass/main'; // Component Styles @import 'components/header'; // ...etc
Inside of main.scss there should only ever by
@import statements, which when the scss is processed will go and fetch the file it asks for and injects it’s content into the file. We import things in a certain order to make sure that the CSS is output correctly and cascades how we want it to.
Scss doesn’t require the file extension on the end of the import statement, it’s pretty smart at going and getting the correct file.
First off, we import the contents of the ‘cascade’ folder, unfortunately scss doesn’t support blob matching natively, so we have to explicitly define each file.
Then we import any external libraries style code, in the above example, we imported the styles required for the Crowd Carousel bower component. Make sure to import it’s src sass so you have the opportunity to overwrite any customisable variables that the library may have.
Lastly we import all of our component styles, this list can get quite long depending on the size of the project.
When writing a new component, don’t forget to add an @import into the main.scss. Otherwise you might be scratching your head wondering why your styles aren’t working!
Every scss file other than
main.scss should have a filename that begins with an
_ this tells the sass processor that this file is a partial and that it’s imported.
As a general rule of thumb, the cascade folder contains all our styles that apply across an entire site. This could be simple things like a CSS reset, to colour definitions or even a complex grid system. There is no defined ‘boilerplate’ for a cascade folder that we use, but most projects have a common set of files along the lines of:
_functions.scss _reset.scss _animations.scss _grid.scss _colours.scss _type.scss _buttons.scss _aspect-ratios.scss _responsive-video.scss _forms.scss _accessibility.scss
The components directory is where the bulk of our styles go. He we place scss files that are responsible to styling specific components. Each component can have it’s own file, or even a folder depending on the size of the component.
In projects that utilise flexible content fields, we like to have a
content-blocks folder that houses all of the component styles that can be dynamically loaded in. This makes things quicker to find and keeps things tidy by matching the layout of the components folder where we place our Twig code.
General SASS guidelines
SASS is awesome. However, there a couple of guidelines we like to follow to keep our scss files simple and easy to follow.
Nesting is a useful feature of SASS, it allows you to easily group up child selectors inside of one parent. This makes it super simple to create styles that only apply to one component. However, sometimes it can become too easy to just keep nestin’ and you can lose track of the specificity of the rules you are creating. Just keep checking that your code is clear and your selectors are easy to determine and understand.
To help keep things tidy and uniform across all our team, we use Editor Config in our projects. This especially helps with SASS when it comes to nesting and helps keep commit logs clear as every developer’s editor will use the same settings. Make sure you have your editor setup to respect and use the projects
.editorconfig file. There are loads of plugins to support almost every editor out there: http://editorconfig.org/#download.
Variables are arguably one of SASS’s best features and we love to use them. However knowing where they’re defined can be a pain. We like to follow the same rules as above, usually a variable should be defined with the cascade. However, if that variable is only used in one component and no where else, it may be suitable to define it at the top of the component’s scss file.