I recently inherited a Drupal 7 theme that did not use CSS preprocessors like Sass or Less. While the CSS files were clearly organized, they contained more than 15,000 lines of code which made maintainability a difficult task. Also, the theme was set up with individual stylesheets for specific breakpoints:
- styles-base.css
- styles-tablet-portrait.css
- styles-tablet-landscape.css
- styles-desktop.css
When I needed to change a style, I would hunt through these four files making liberal use of Sublime Text’s search functionality. Not very efficient. How could I make this theme easier to work with? Aside from moving from traditional CSS to Sass, I wanted to organize the styles in a more component-based fashion. This is what I did.
Step 1: Create a sass file and set up compilation method
The first thing I did was set up Gulp to compile the Sass; you may have another method that you use. I now have one single empty Sass file that will compile into a single CSS file. I also installed breakpoint sass to handle mediaqueries and fallbacks for older browsers.
Step 2: Copy styles from the CSS into Sass
Next, I copied the styles from each CSS file into my Sass file starting with styles-base.css, since these apply to the site at all breakpoints. I wrote a mediaquery for "tablet portrait" and pasted the style-tablet-portrait.css code within that mediaquery, and repeated this step for tablet-landscape and desktop. At this point I compiled the CSS again to ensure that the appropriate styles are getting triggered at the correct breakpoints.
Step 3: Remove the CSS files
After I had removed all the styles from CSS and ported them into my Sass file, I deleted the four CSS files. I then updated the theme.info file so that it points to the new CSS file (and removed references to the other four CSS files). I tested the theme again, this time in the browser.
Step 4: Refactor Sass
I also want to compress the styles so that they make use of Sass’s nesting capabilities. I use the .scss format which is nice because I don’t need to change the CSS to compile at all. If you use the .sass format, or if you want to take full advantage of Sass’s nesting capabilities, you may want to use an app like this or this. I also created variables for things like color which allowed me to standardize the theme’s color palette. In this particular theme, I discovered that it was using seven different variations of the color orange, some of which were indistinguishable from each other.
Before and after with nested code:
Step 5: Break out into components
Everything is compiling properly. The theme looks good in the browser. I’m done, right? Well, not quite. What I really want to do is make my sass component-centric rather than breakpoint-centric. As you can see, the header styles are in three locations in the scss file.
Global header styles:
Header styles for tablet landscape:
Header styles for desktop:
I will begin by making a partial for all #header styles and place it in the components folder: /themename/sass/components/_header.scss
Then, within this partial I set up my styles and add breakpoints wherever I need them, like this:
In doing this, I can eliminate redundant code and use breakpoints to override only those styles that need to be overridden.
As you can see, you’ll be changing a lot of code. In my case, the styles were written with great specificity (multiple selectors chained together), which meant that changing the order or leaving out a selector could have drastic implications with regard to the theme. So, I cannot emphasize this enough: test your site as you make these changes! If CSS or visual regression testing is in your toolbox, this would be a great time to use them. At the very least, you should compare the site using the old code and one with the new one in your browser.
And I will repeat this as time permits for all the components until my original scss file is a list of @import statements linking to partials. Now my theme is more manageable—whenever I need to change something pertaining to the header, I know exactly which file I need to edit.
This process can be time consuming so it’s important to assess what you need to make this work for you. Maybe you won’t have enough time to move all the components into separate partials in one sitting. You may decide to move the components to partials as you work on them. It can be an arduous process but the long-term payoff is worth it.
Additional Resources
Using SASS Breakpoints Effectively | Blog Post
Top Drupal 7 Modules: Final Edition | Blog Post
SASS Breakpoint Mixin Meets IE8 | Blog Post