Drupal Meets Sass: Getting Started With Aurora (Part 2)

Mike Crittenden, Software Architect
#Drupal | Posted

All of the fine folks who worked through Part 1 of this series now have their very own Sass/Compass/Aurora development environment and are rip roaring to go. If this doesn't describe you, head on over to the last post and start there. If it does, then we ride!

In this post, we'll run through a Sass/Compass example, then we'll dig into Aurora a bit more and take a look at the goodies and code structure it provides, along with some notes on debugging tools.

Finally, some (Sass) code

You waited through the whole last post--you've earned it. Let's look at some code.

Before we dig into Aurora specifically, let's run through a quick Sass primer. For this example, we'll be overhauling this snippet of CSS:

  1. .nav {
  2. background: #131313;
  3. border: 1px solid #fafafa;
  4. }
  5.  
  6. .nav ul {
  7. list-style-type: none;
  8. margin: 0;
  9. padding: 0;
  10. }
  11.  
  12. .nav ul li {
  13. margin: 0;
  14. padding: 0;
  15. display: inline;
  16. background: #fafafa;
  17. }
  18.  
  19. .nav ul li a {
  20. color: #131313;
  21. }

Looks pretty typical right? It's just a basic horizontal nav with a border and some custom colors.

Let's identify some crappy CSS-isms of this code.

  • We have hardcoded hex colors repeated in different places. If a color choice changes, we have to change it multiple times in the code.
  • Selectors get long and repetitive once you're a few levels deep--too much typing. Plus, long selectors make file sizes slightly bigger, which can add up on large stylesheets served to mobile devices.
  • We have some repeated rules in both the 2nd and 3rd selector. This violates DRY. Plus, again, too much typing.
  • CSS is booooooring.

Let's convert it to SCSS and see how it can be improved. First, we can rewrite the code by taking advantage of Sass's nested rules.

  1. .nav {
  2. background: #131313;
  3. border: 1px solid #fafafa;
  4.  
  5. ul {
  6. list-style-type: none;
  7. margin: 0;
  8. padding: 0;
  9.  
  10. li {
  11. margin: 0;
  12. padding: 0;
  13. display: inline;
  14. background: #fafafa;
  15.  
  16. a {
  17. color: #131313;
  18. }
  19. }
  20. }
  21. }

Whew, that really cleaned things up a bit. Now let's see what we can do about those hardcoded colors.

  1. $lightgray: #fafafa;
  2. $darkgray: #131313;
  3.  
  4. .nav {
  5. background: $darkgray;
  6. border: 1px solid $lightgray;
  7.  
  8. ul {
  9. list-style-type: none;
  10. margin: 0;
  11. padding: 0;
  12.  
  13. li {
  14. margin: 0;
  15. padding: 0;
  16. display: inline;
  17. background: $lightgray;
  18.  
  19. a {
  20. color: $darkgray;
  21. }
  22. }
  23. }
  24. }

Nice! Now we can add those colors to more elements without having to memorize or copy/paste the hex value, and if we need to change one of them sitewide, we're only changing it in one place.

How about taking advantage of some Compass goodies for common tasks, such as forcing the <ul> to be laid out horizontally?

  1. $lightgray: #fafafa;
  2. $darkgray: #131313;
  3.  
  4. .nav {
  5. background: $darkgray;
  6. border: 1px solid $lightgray;
  7.  
  8. ul {
  9. @include inline-list; /* Yay! */
  10.  
  11. li {
  12. background: $lightgray;
  13.  
  14. a {
  15. color: $darkgray;
  16. }
  17. }
  18. }
  19. }

And just like that we're back in business. This is just the tiniest tip of the Sass/Compass iceberg, and you should definitely browse through the documentation for Sass and the Compass reference to see what else you can take advantage of. Plus, if you just found yourself wanting some more majestic examples of what Sass can do for you, check out Will O'Beirne's recent post on making use of Sass for the Pac-12 conference site.

With some Sassy knowledge under your belt, let's move along to the specifics of Aurora.

Aurora's goodie bag

Sass and Compass by themselves are jam packed with cool stuff so Aurora doesn't need to add much on its own, but it does give you a few extra things to play with.

  1. Singularity is a Sassy grid system. Aurora used to encourage Susy grids but Singularity is the new way forward. The fact that Singularity is built by the core Sass team is gravy.
  2. Breakpoint makes it simple to write media queries in Sass and has some preset media queries to use.
  3. Color Schemer is a toolkit for generating color schemes (I know, weird name right?) and altering existing colors such as altering lightness or tint.
  4. Sassy Buttons are beautiful and simple CSS3 buttons created in a few lines of Sass.
  5. Toolkit is a "swiss army knife for Progressive Enhancement and Responsive Web Design" and includes a lot of miscellaneous helpers lacking in vanilla Sass/Compass.
  6. Compass Normalize allows you to use normalize.css without having to download it separately.

Aurora comes with all of this out of the box, so feel free to start using anything that you find useful--no setup required.

Aurora's code structure

Open up your custom subtheme's directory and check out the "sass" directory. Assuming you used the "Corona" flavor of Aurora, it should look like this:

  1. ├── maintenance.scss
  2. ├── partials
  3. │ ├── _base.scss
  4. │ ├── design
  5. │ │ └── _design.scss
  6. │ ├── _functions.scss
  7. │ ├── global
  8. │ │ ├── _defaults.scss
  9. │ │ ├── _extendables.scss
  10. │ │ ├── _forms.scss
  11. │ │ ├── _global.scss
  12. │ │ └── _type.scss
  13. │ ├── _mixins.scss
  14. │ ├── README.md
  15. │ └── _variables.scss
  16. ├── print.scss
  17. ├── README.md
  18. └── style.scss

So let’s go down the line here.

  • maintenance.scss is used to generate maintenance.css which is specifically for styling the maintenance page. Add custom maintenance page styles here.
  • print.scss is used to generate print.css which is specifically for styling printed web pages. Add custom print styles here.
  • style.scss is used to generate style.css which is basically the compilation of all your SCSS into a single file which the browser can see. You shouldn’t add any code to this file besides perhaps some additional imports if you add new partials.
  • partials/ is where your SCSS is actually going to go. We’ll take a deep dive in a moment.

And if we dig into the partials directory a bit more, we discover:

  • _base.scss contains imports to partials that need to be included on all three generated stylesheets (i.e., print.css, maintenance.css, and style.css).
  • _functions.scss can hold all of your custom function partials.
  • _mixins.scss holds all of your custom mixins
  • _variables.scss holds custom variables in addition to some defaults that Aurora gives you. These include colors, font stacks, and breakpoints, among other things.
  • design/ is meant to contain element-specific design styles. I recommend splitting these types of styles into files per site sections or site pages or features, so that you’re not clumping all non-global design styles into one file.
    • _design.scss should be used to include the other (custom made) partials in the "design" directory.
  • global/ is where any general styles that should apply to the entire site.
    • _defaults.scss should contain any catch-all default styles that don’t belong in the other files in this directory.
    • _extendables.scss is for any basic global classes you like to create and use such as .clearfix or .nopad.
    • _forms.scss should contain default form styles.
    • _global.scss contains no custom styles and merely imports the other files.
    • _type.scss sets default typographical styles.

Some notes on debugging

A slight downside to using Sass is that the CSS that your browser sees isn't CSS that you wrote, it's CSS that was generated from the Sass that you wrote. The reason this is bad is that if you inspect an element in your browser's development tools, the line numbers and code are different than in your Sass source.

For example, say you want to reduce the padding on an element. So you open up Firebug or Chrome's dev tools and inspect the element. You can see the CSS selector that targets it and the rule that sets the padding, and you can change it within the dev tools, but that's not the same code that's in your Sass, so you have to figure out where that code is in your source files. Or even worse, maybe you're using a mixin or a variable rather than a raw "padding: 10px" property so that's another level.

Luckily, this is no longer an issue due to Sass source maps. Chrome is smart enough to connect to your Sass source files and transparently use them instead of the compiled CSS when inspecting elements.

To enable this, make sure "debug = true" is uncommented in your theme's config.rb. Also, Chrome at the time of this writing requires you to open up chrome://flags and check the "Enable Developer Tools experiments" flag.

Once that's done and Chrome has been restarted to pick up that change, open up the dev tools and click the cog icon, click the "Experiments" tab, and check the "Support for Sass" checkbox. From here on out, Chrome's dev tools will show you the Sass source of each of your styles whenever you're inspecting an element rather than the compiled CSS source.

You can also go to the "General" tab and click "Auto-reload CSS upon Sass save" so that you don't have to manually refresh your page when you make a change to your Sass files. This little feature can really change your world.

Getting real

We've talked in abstracts for long enough. In the next and final post of the series, we'll walk through theming a simple responsive design using Aurora, start to finish. Check out Part 3!

Any questions so far? Comment away!

Mike Crittenden

Mike Crittenden

Software Architect