When we left off, our sass
directory looked like this:
# Inside the custom theme directory
sass
├── _init.scss
├── base
├── components
├── layouts
├── lib
│ ├── bourbon
│ ├── font-awesome
│ └── neat
└── styles.scss
At this point we’re ready to start styling. Let’s take a look at the three folders that will hold our custom .scss
files, which are loosely based on SMACSS. Acquia has a nice writeup of how SMACSS principles can be applied to Drupal, but I like to simplify it even further.
Base
I personally only have three files in the sass/base
directory. Don’t forget that we already imported these three partials in styles.scss
.
For full examples of each of these files, check out our base
directory.
_normalize.scss
This is simply normalize.css
renamed as _normalize.scss
- remember that CSS is valid SCSS. Thoughtbot recommends using normalize.css
as your CSS reset along with Neat. Regardless of which reset you use, include it in base
.
_base.scss
This is for HTML element styles only. No layout, no classes, nothing else. In here I’ll apply font styles to the body and headings, link styles to the anchor element, and possibly a few other site-wide styles.
_variables.scss
This is where I house all of my Sass variables and custom mixins. I typically have sections for colors, fonts, other useful stuff like a standard border radius or spacing between elements, variables for any Refills I’m using, and custom mixins.
I’d definitely recommend including _normalize.scss
in base
if you’re using Neat, but other than that do what works for you! If you’re following my method, your sass
folder should be looking like this:
# Inside the custom theme directory
sass
├── _init.scss
├── base
│ ├── _base.scss
│ ├── _normalize.scss
│ └── _variables.scss
├── components
├── layouts
├── lib
│ ├── bourbon
│ ├── font-awesome
│ └── neat
└── styles.scss
Layouts
This directory holds page-wide layout styles, which means we’ll be making heavy use of the Neat grid here. This is flexible, but I recommend a single .scss
partial for each unique template file that represents an entire page. Think about what works best for your site. For the sake of our example, let’s say we’re creating _front-page.scss
and _node-page.scss
. I like to also create _base.scss
for layout styles that apply to all pages.
Remember that these styles only apply to the page’s layout! I occasionally find myself moving styles from the layouts
directory to base
or components
when I realize they don’t only define layout. In these partials, you should be doing a lot of grid work and spacing. This is the entirety of my sass/layouts/_base.scss
file on our mapping site:
/**
* @file
*
* Site-wide layout styles.
*/
body {
@include outer-container();
main {
@include span-columns(10);
@include shift(1);
@include clearfix;
h1 {
margin-top: em($navigation-height) + $general-spacing;
}
}
}
We’re almost there:
# Inside the custom theme directory
sass
├── _init.scss
├── base
│ ├── _base.scss
│ ├── _normalize.scss
│ └── _variables.scss
├── components
├── layouts
│ ├── _base.scss
│ ├── _front-page.scss
│ └── _node-page.scss
├── lib
│ ├── bourbon
│ ├── font-awesome
│ └── neat
└── styles.scss
Components
In SMACSS this is called “modules,” but that gets a little confusing in Drupal Land. This is for applying layout and theme styles to smaller chunks of your site, which in Drupal typically means regions. Create a separate partial for each region, or if you have several distinct components within a region, consider a separate partial for each of them.
Let’s say we created partials for the header, footer, and sidebar regions, plus one for non-layout node page styles. At this point, our sass
directory is looking like this:
# Inside the custom theme directory
sass
├── _init.scss
├── base
│ ├── _base.scss
│ ├── _normalize.scss
│ └── _variables.scss
├── components
│ ├── _node-page.scss
│ └── regions
│ ├── _footer.scss
│ ├── _header.scss
│ └── _sidebar.scss
├── layouts
│ ├── _base.scss
│ ├── _front-page.scss
│ └── _node-page.scss
├── lib
│ ├── bourbon
│ ├── font-awesome
│ └── neat
└── styles.scss
Now we’ve got a nicely organized, easy to navigate Sass directory, ready to hold your styles and compile them into one beautiful CSS file!
But how do we ensure that our one CSS file really is beautiful? Check out my final post about best practices for writing Sass that you can easily maintain or pass off to another developer.