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.