SMACSS your SASS

I'll let you in on a secret...I've only been coding and making websites for about four years now. Don't tell anyone. When I started everything I did was in HTML and CSS. I wasn't even using an IDE, it was all done by "hand" as they say. Looking back on it now, all I can think is...the horror

Thankfully I was introduced to technologies like SASS, code editors like Atom and IDEs such as PHPStorm and those days are behind me. Recently, however, I was thrown back to these neanderthal days when I was asked to look at someones site and see if I couldn't make it look "better" on mobile. I was smacked in the face by over 1700 lines of vanilla CSS. Line after line of specific selectors, much of it...id's. Needless to say, this was not going to work, but I had a job to do so I was going to make sure that I left things better than I found them.

Starting with Grunt I set about incorporating a modern workflow into the project. Since my first order of business involved lots of styling, I used grunt to set up SASS, which is in my opinion, the only way to write modern styling sheets.

In the off chance you haven't used used it (or another CSS preprocessor,) do yourself a favor and take a day to learn it. I will simplify your life and you'll be happier, more productive and a better person all around.

Here at Code Koalas, we use Grunt to do a ton of things, but since this project was small and they only wanted the mobile styling fixed up, I just set up SASS. To make sure that I wasn't just going to create more work for me (or another developer) in the future the first order of business was to set up a proper file structure for the SASS files. Doing this makes it easier to be able to jump back into a project down the road and figure out where all the pertinent bits are. What I ended up with was this structure:

scss
|--common
|    |--styling elements for the whole site
|--front-page-slider
|    |--styling for JQuery slider
|--modules
|    |--Drupal module and block styling
|--navbar
|    |--custom CSS for navbar
|--pages
|    |--specific page styling
|--views
|    |--Drupal views styling
|--styles.scss

Since SASS itself is only a preprocessor, it doesn't have any naming conventions for your files. You could, and I've seen this, just create one gigantic scss file and cram all of the styling in there. Of course this doesn't improve the situation, so what we need is a content strategy for our files. For this I used the philosophy of SMACSS or Scallable and Modular Architecture for CSS. SMACSS was developed by Jonathan Snook as a framework for breaking CSS into smaller, more manageable chunks. If you haven't read his book (which is available for free here), you should go do it right now. Go ahead I'll wait...

Granted, SMACSS naming convention is written to be applied to the classes of CSS and not necessarily to the file structure. Since I was coming into this project after it was technically done I couldn't do that, but I could use the same philosophy in the naming of folders and files. After the basic folders where in place I set about breaking the original CSS file into manageable chunks. To ensure proper inheritance of styles and ensure easy readability, I limit the size of my SASS files to no more than 100 lines. If I find that the styling takes more than this, I'll employ one of two strategies.

The first, and better in the long run, of these is to make as many styles as possible be inherited. This is easily done with nested selectors and getting rid of duplicate declarations that are a necessity of vanilla CSS.

If this isn't enough, and indeed when working with Drupal it can sometimes not be, I'll break out chunks of the code into a separate style sheet then use @import to add the styling where it needs to be. This isn't the best approach, but I have found that in the interest of keeping my SASS files small, it is some times necessary.

To wrap everything up into a nice little (or big) CSS file, I have the styles.scss file that is used solely to @import all of the smaller files. Doing it this way also allows me to import chunks at specific points in the final CSS. For instance, I may have some global styles for all the button elements, but on this one specific page it needs to be a ghost button. By importing the ghost styling after the button styling, proper inheritance is ensured and I don't have to re-write all the styles for a button.

I still have to go through and fix all of the styling to make the site look better on mobile, but now I have a structure that makes it easier. Now when I'm trying to figure out why the navigation on the footer is stacking instead of displaying inline, I'll know exactly where to look.