Responsive Theming for Drupal (2014)
Chapter 4. Responsive Theming With Aurora
Drupal theming trends have slowly but surely been keeping up with the rest of the frontend world, and one of the leaders of this movement is Sam Richard (aka Snugug) and his Aurora theme. Aurora integrates Sass and Compass into a Drupal theming workflow, and is optimized for mobile-first and responsive design.
Beyond that, it’s fairly minimal as base themes go—it basically integrates Sass and Compass into Drupal, sets up a code structure for your Sass, and leaves the rest of the decisions up to you.
In this chapter, we’ll put the Sass and Compass intro from the last chapter to good use by walking through the setup and configuration of both the theme itself and a Sass/Compass theming development environment. We’ll be touching the command line a bit, but don’t fret, it’s very simple.
Pros and Cons
Aurora is nice because it’s a nimble, lightweight theme with just enough functionality to make you feel like you’re not missing out. It sets you up with Sass/Compass and gives you some starter variables and a Sass grid system (Singularity, which we’ll get to later) but doesn’t hand you a bulky UI for managing layouts or anything like that.
Aurora also gives you the power of the absolute latest and greatest frontend tools. You get Sass/Compass complete with a bunch of useful plug-ins, Bower for package management and Grunt for task management (complete with “Sass compiling, JS hinting, Image Optimization, and app-free live reloading out of the box”), as well as LiveReload and a Ruby gem for creating subthemes. If you haven’t heard of some or all of these tools, that’s OK—the point is that all of these are becoming the new-school standard practice in the frontend world, and Aurora is one of the very few themes making an effort to keep up with that. It’s a lot of fun; it feels young and fresh.
That said, it’s worth noting that if you like GUI integration for your base themes (such as a clicky layout/grid builder or a bunch of font/color settings) then you’re basically up a creek with Aurora, because that’s not how it’s done.
It also has a smaller community than Zen or Omega, which can make finding help a bit more difficult. Plus you get the inherent risks of using a bunch of newish technologies like Bower and Grunt—things break, documentation isn’t great, whatever.
Getting Started
Since Aurora makes use of Sass and Compass rather than just vanilla CSS, the installation is a little more involved than with other base themes. Let’s go ahead and get that out of the way.
Step 1: Install Sass/Compass
First, you’ll need to install Sass and Compass as outlined in Chapter 3.
Step 2: Install Aurora
Once you have Sass/Compass installed, you’re ready to grab Aurora. First, you’ll want to install the “compass-aurora” gem using:
gem install compass-aurora
Then, just download the Aurora theme from Drupal.org as you would any other theme. You’ll also need to install the required Magic module for lots of helpers that Aurora integrates, and you might want to install the highly recommend HTML5 Tools module as well. If you’re curious, you could also check out Aurora’s list of recommended modules that you might find useful.
Step 3: Create Your Custom Subtheme
Once everything is installed, you’re ready to generate your custom subtheme. There are three different flavors of subthemes to choose from: Corona, Polaris, and Aurora.
Corona is a subtheme which doesn’t give you much predefined organization of your Sass. Rather, it hands you a base folder, a global folder, and a design folder, and leaves the rest up to you. It’s the simplest of the three, so it’s the one we’ll be using in this book’s examples. To use Corona, run:
compass create YOURTHEMENAME -r aurora --using aurora/corona
Polaris makes it easy to write your code in accordance with SMACSS and includes folders/partials laid out according to the guidelines of SMACSS. To base your subtheme on Polaris, run:
compass create YOURTHEMENAME -r aurora --using aurora/polaris
Aurora is the default. It’s based around the idea that you start your theming with a style guide, and as you theme you keep layout and design rules separate. As such, in addition to a global folder, it also includes a style guide folder along with a layout folder and a design folder. To use Aurora, run:
compass create YOURTHEMENAME -r aurora --using aurora
Once you have your subtheme created, you’ll want to install its dependencies. So cd into your subtheme’s directory and then run:
bundle install
NOTE
Note that if you get Command Not Found errors for bundle, you may have to install it using:
gem install bundler
Step 4: Configure and Run Compass
At this point, you have everything installed and a custom subtheme set up, so you’re ready to roll.
First, you should open up your subtheme’s config.rb file and take a glance at the default settings to get a feel for the options and see if you’d like to change anything. Particularly, you will likely want to uncomment the following line so that your browser’s dev tools can map the generated CSS to the location in the source Sass files:
# In development, we can turn on the debug_info
# to use with FireSass or Chrome Web Inspector.
# Uncomment:
# debug = true
Once you’re happy with that, all you need to do is tell Compass to start watching your Sass files for changes, so it knows when to recompile your CSS. So make sure you’re still in your subtheme’s directory, and then run:
bundle exec compass watch
NOTE
Note that you could technically also just run compass watch but the bundle exec part makes sure that it uses the gem versions specified by Aurora.
Now, any time you make a change to any Sass files in your subtheme, Compass will see that and will instantly regenerate the CSS the browser uses. So by the time you switch to your browser and refresh the page, you should see your newly generated CSS.
Note that you’ll probably be running that four-word command every time you start working on your theme and it can get kind of tiresome. You might want to add something like this to your bash or zsh config so you can just type becw instead:
alias becw='bundle exec compass watch'
Step 5: Perform a Sanity Check
Just to make sure everything’s working correctly, you’ll want to open up one of your subtheme’s Sass files (e.g., sass/partials/design/_design.scss) and make an obvious change such as the following:
body {
background: red;
}
Then watch the command-line output in the Terminal where Compass is running. You should see it telling you that it detected a change and is rebuilding style.css:
Change detected at 10:34:47 to: partials/design/_design.scss
overwrite stylesheets/style.css
Once that completes, switch to your browser and refresh your page. If your subtheme is set as the default theme and everything went according to plan, you should be presented with a horrible-looking red background. Success! You’re ready to work.
Digging Into Aurora
At this point, everything is installed and the groundwork has been laid. So open up your subtheme’s directory and start taking a look around to get acquainted with your new best friend!
Aurora’s Goodie Bag
Remember that Aurora is basically a simple connector from Sass/Compass to Drupal and it really doesn’t provide a ton of functionality outside of that. But it does bring a few goodies that aren’t in vanilla Sass/Compass which you should know about:
§ Singularity is a Sassy grid system.
§ Breakpoint makes it simple to write media queries in Sass.
§ Color Schemer is a toolkit for generating color schemes and altering existing colors such as adjusting lightness or tint.
§ Sassy Buttons are beautiful and simple CSS3 buttons created in a few lines of Sass.
§ Toolkit is a Swiss Army knife for progressive enhancement and responsive web design and includes a lot of miscellaneous helpers.
§ Compass Normalize allows you to use normalize.css without having to download it separately.
So you have a basic grasp of the hotness that Sass, Compass, and Aurora bring to the table. Now let’s dig into the code.
A Primer on Aurora’s Sass Structure
Check out the sass/ directory. Assuming you used the Corona flavor of Aurora, it should look like this:
├── maintenance.scss
├── partials
│ ├── _base.scss
│ ├── design
│ │ └── _design.scss
│ ├── _functions.scss
│ ├── global
│ │ ├── _defaults.scss
│ │ ├── _extendables.scss
│ │ ├── _forms.scss
│ │ ├── _global.scss
│ │ └── _type.scss
│ ├── _mixins.scss
│ ├── README.md
│ └── _variables.scss
├── print.scss
├── README.md
└── style.scss
3 directories, 15 files
Let’s go down the line here and dig in deeper to see what each file and directory is used for:
§ 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 except 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 there 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 separate files per section, per page, or per feature, 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 reside.
§ _defaults.scss contains any catchall 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.
Getting to Work
Finally! Let’s add some pretty! Have you already run the following command to tell Compass to watch for changes to your Sass?
bundle exec compass watch
Yes? Great! No? Run it now!
By now you should have a basic idea of how to rock your Aurora subtheme since you know the basics of Sass and Compass. So let’s work through a real-world example.
Remember Riley and his turnip sauce business? Let’s talk our way through rebuilding his (nonexistent) site in Drupal with Aurora.
Let’s start with the variables, so open up sass/partials/_variables.scss. In our case, we basically only need to store the font stacks and colors we’re using. Luckily, Aurora already comes with some nice font stacks:
$times-new-roman: "Times New Roman", Times, Georgia, "DejaVu Serif", serif;
$times: Times, "Times New Roman", Georgia, "DejaVu Serif", serif;
$georgia: Georgia, "Times New Roman", "DejaVu Serif", serif;
$verdana: Verdana, Tahoma, "DejaVu Sans", sans-serif;
$tahoma: Tahoma, Verdana, "DejaVu Sans", sans-serif;
$helvetica: Helvetica, Arial, "Nimbus Sans L", sans-serif;
$arial: Arial, Helvetica, "Nimbus Sans L", sans-serif;
So all we need to do is tell Aurora that we want to default to the $georgia stack, and we can do that a little farther down by changing the $font-body property to $georgia. While we’re at it, let’s make sure that forms use a nice Arial-based stack.
$font-body: $georgia;
$form-font-family: $arial;
So that gets our fonts in order. Now let’s add some color. We only need three colors (besides white and black):
§ Light gray (#AAA)
§ Dark gray (#333)
§ Turnip purple (#D900BC)
A few lines below the font variables, we can see some color variables that hold default branding colors for some popular sites (like YouTube and Facebook). We can add our colors there like so:
$color-turnip: #D900BC;
$color-lightgray: #AAA;
$color-darkgray: #333;
That does it for the variables, so we can move on to some default styles for elements. For example, we have a form, so let’s set up some default form styles. Open up sass/partials/global/_forms.scss and add some basic input styling:
textarea {
height: 10em;
}
input,
button,
select,
label,
textarea {
font-family: $form-font-family;
}
label {
display: block;
margin-top: 20px;
font-weight: bold;
text-transform: uppercase;
}
input[type="text"],
input[type="password"],
input[type="email"],
textarea,
select {
display: block;
border: 1px solid $color-turnip;
font-size: 16px;
margin-top: 10px;
padding: 5px;
&:focus {
border: 1px solid $black;
}
}
In a regular site that’s a little more involved than Riley’s, you’ll also want to add some default typography styles to _type.scss, set up some reusable classes in _extendables.scss, and maybe add some global element-specific styles (for things like tables, horizontal rules, or other non-formy and non-typey things) to _defaults.scss.
Now how about some individual site sections, like the header? If you recall, our boring old static CSS for the header looked like this:
.header {
background: black;
width: 100%;
overflow: hidden;
}
.header h1 {
margin: 0;
padding: 0;
float: left;
font-size: 30px;
color: white;
font-weight: normal;
margin: 10px;
}
.header ul {
float: right;
margin: 17px 10px 10px;
}
.header ul li {
display: inline;
padding: 0 10px;
}
.header ul li a {
color: white;
text-decoration: none;
text-transform: uppercase;
font-weight: bold;
font-size: 16px;
font-family: $form-font-family;
}
.header ul li a:hover {
color: #D900BC;
}
We can clean that up a lot with some help from Sass. Open up sass/partials/design/_design.scss and you’ll find yourself staring at an empty file. Rather than adding code right there, let’s split it up a bit. Add the following line to _design.scss, which tells it to include a new header design file:
@import 'header';
Now you can create a new file at sass/partials/design/_header.scss, which looks like this:
#header {
background: $black;
width: 100%;
overflow: hidden;
h2 {
margin: 0;.
padding: 0;
float: left;
font-size: 30px;
color: white;
font-weight: normal;
margin: 10px;
}
ul {
float: right;
margin: 17px 10px 10px;
li {
display: inline;
padding: 0 10px;
a {
color: $white;
text-decoration: none;
text-transform: uppercase;
font-weight: bold;
font-size: 16px;
font-family: $form-font-family;
&:hover {
color: $color-turnip;
}
}
}
}
}
Starting to get the idea? From this point, you’ll just need to create a new file in /sass/partials/design for each of your major site sections. In the case of Riley’s turnip sauce business, for example, you’d want a _hero.scss for the big hero bar under the header, _footer.scss for the bottom,_photos.scss for the three-column photo display, and _orderform.scss for the display of the order form.
NOTE
Remember, you don’t by any means have to stick with the code structure provided by Aurora. For example, a lot of themers prefer to have layout rules separated from more designey rules, so you could create a sass/partials/layouts directory to hold them.
Making It Responsive
Finally, we’ve landed. Let’s take a peek at how to make a responsive theme using Aurora. This is where the theme really shines.
To do this, we’ll make use of two things:
§ Singularity, the Sassy grid system that Aurora prefers.
§ Breakpoint, a mixin that lets you include media queries without breaking a sweat.
Breakpoint is the easiest to understand, so we’ll take a look at that first. Here’s a familiar looking bit of CSS that we’ll start with:
.sidebar {
width: 100%; /* Full width on mobile */
}
@media (min-width : 768px) and (max-width : 1024px) {
.sidebar {
width: 400px; /* Fixed width for tablets */
}
}
@media (min-width : 1025px) {
.sidebar {
width: 25%; /* Fluid width for desktop */
}
}
So here we have a basic mobile-first CSS snippet that tells the browser what width the sidebar should be at different resolutions. Specifically, full width on mobile, fixed width on tablets, and fluid width on desktop.
Now, when we convert this to Sass and make use of the Breakpoint mixin, it looks like this:
// Set up our variables in _variables.css.
$tablet: 768px 1024px;
$desktop: 1025px;
// Set up your layout where you like layout rules.
// I prefer separate files under a custom sass/partials/_layout folder.
.sidebar {
width: 100%;
@include breakpoint($tablet) {
width: 400px;
}
@include breakpoint($desktop) {
width: 25%;
}
}
Not only is this a lot cleaner and more easily readable, it’s also a lot more maintainable since you’re not hardcoding media query resolutions all over the place.
So that handles media queries. Now how about the grid? This is where things get a little interesting.
For example, let’s walk through a simple three-column desktop layout on that collapses to two columns on tablets and a single column on mobile.
Here’s what it should look like on desktop:
=================================================
| SIDEBAR | CONTENT | SIDEBAR |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
=================================================
And on tablets, we get two columns over one.:
=====================================
| SIDEBAR | CONTENT |
| | |
| | |
| | |
| | |
| | |
=====================================
| SIDEBAR |
| |
| |
| |
=====================================
And on mobile, we drop down to a single column layout:
=========================
| SIDEBAR |
| |
| |
| |
=========================
| CONTENT |
| |
| |
| |
=========================
| SIDEBAR |
| |
| |
| |
=========================
So let’s run through setting these up. First, we tell Singularity how many columns we want per layout, like so:
$grids: 1 // Mobile
$grids: add-grid(2 at 768px) // Tablet
$grids: add-grid(1 3 1 at 1024px) // Desktop
As you can (maybe not) see, the $grids property tells Singularity how to set up our grids. If you give it a single number, it just creates that many equal-width columns. If you give it multiple numbers, it creates one column per number, and uses the numbers to determine the relational size between them.
Confused yet? Basically, this just means that if you want a symmetric grid, just tell it how many columns you want. If you want an asymmetric grid, you give it one number per column, where the number is how wide that column is compared to the others. So in our desktop example, we said “1 3 1” which means to create 3 columns, where the first and third are 1/5 of the total width, and the middle one is 3/5 of the total width.
Also of note is the fact that we default to the mobile layout, and then add in grids for tablet and desktop resolutions since we’re going with mobile first (like we talked about in Chapter 1). If you want to be super fancy, you can use the $tablet and $desktop variables created in the Breakpoint section here instead of hardcoding widths.
So now that Singularity knows about our columns, what about the gutters? This part’s easy. Just tell it how big the gutter should be in relation to a single column. So if you want the gutter to be 1/4 the size of a single column, you just need to say:
$gutters: 1/4;
That gives us the foundation for our grid. Now how about actually putting content into it? This is where the “grid-span” mixin comes into play.
Let’s say that the markup for our page looks like this:
<div class="sidebar-first"></div>
<div class="content"></div>
<div class="sidebar-last"></div>
Then to get our desktop layout, all we’d have to do is this:
@include breakpoint($desktop) {
.sidebar-first {
@include grid-span (1, 1);
}
.content {
@include grid-span (3, 2);
}
.sidebar-last {
@include grid-span (1, 5);
}
}
The first number you pass to grid-span() tells it how many columns you’d like that element to span, and the second number tells it which column you want it to start on. So since we’re basically working with a five-column 1-3-1 layout on the desktop, we tell Singularity to let the sidebars span the first and last column, and the content to fill in the space between them.
And of course, since we’re interested in responsiveness, we’ll need to add rules for tablet and mobile. Here’s what the whole shebang looks like when you smush it together:
// _variables.scss
$grids: 1 // Mobile
$grids: add-grid(2 at 768px) // Tablet
$grids: add-grid(1 3 1 at 1024px) // Desktop
$gutters: 1/4;
// _layout.scss or something like it
.sidebar-first {
@include grid-span (1, 1); /* Mobile/Desktop/Tablet */
}
.content {
@include grid-span (1, 1); /* Mobile */
@include breakpoint($tablet) {
@include grid-span (1, 2); /* Tablet */
}
@include breakpoint($desktop) {
@include grid-span (3, 2); /* Desktop */
}
}
.sidebar-last {
@include grid-span (1, 1); /* Mobile */
@include breakpoint($tablet) {
@include grid-span (2, 1); /* Tablet */
}
@include breakpoint($desktop) {
@include grid-span (1, 5); /* Desktop */
}
}
Committin’ and Quittin’ Time
So you’ve done a solid day’s theming, and you have a newfound love of Sass and Compass. Oh joy! Now you’re ready to commit your changes to version control. (You are using version control, right?)
There’s a bit of a debate on whether you should commit the compiled CSS to your repository or have it auto-generate on the server instead. Both approaches have their pros and cons.
If you decide to commit your generated CSS, you don’t have to worry about adding a server-side build to compile it for you. On the other hand, if you only commit your Sass, you can rest assured that there is one final source of truth in the CSS (i.e., whatever the server itself compiles) rather than whatever each developer’s (assuming it’s a multiperson dev team) Compass version decides to spit out (thus saving yourself some possible merge conflicts).
Whatever you decide, make sure that your entire team is on the same page about it.