Happy Cog Starter Files 2016
By Allison Wagner | Happy Cog Alumna
I spent close to 7 years as a front-end developer at Happy Cog and in that time I’ve seen our discipline go through many great changes — from spacer gifs to responsive web design, we’ve all iterated quite a bit. This rate of change is one of the things I most love about front-end — the collaborative, communicative community that pushes us all forward whether we like it or not. As process has evolved, so too has it improved.
From the days of cutting images for titles to fully responsive Sass builds, I wanted to enumerate on the current state of our front-end toolkit at Happy Cog, I’m super proud of our custom blend of tools and techniques so it felt right to share.
Consider this a very high-level primer of the tools and techniques we’re leveraging these days. This is by no means an in-depth account of each, if something piques your interest there are links below for you to explore further. Really, I just wanted to expose our secret blend of CSS front-end starter files naming conventions, basic gruntfile.js, syntax, coding methodology etc.
Here are the main benefits to our approach to CSS.
- It’s fast.
- It’s clear.
- It’s teachable.
In terms of general guidelines, we follow Harry Roberts’ excellent doc. One addendum to his document is that we don’t abbreviate any words when naming classes to reduce ambiguity and help dev’s learn the codebase quicker:
Folder Structure and File Namespacing
You’ll see it’s all, for the most part, directly nested inside the Sass folder. Instead of folders, we use namespaces to organize (thanks TJ Pitre for the tip!). Config files set up our grid, map functions, media queries, variables, and imports. Library files contain our base styles where we define global elements: borders, ornaments, our tools classes, our type styles etc. Instead of creating 25 module SCSS partials, we section off the majority of them into a file called _module.sections.scss. Object files contain small repeating elements. The difference between objects and modules is that modules are are divisible and objects are not.
We use include media to manage our breakpoints these days. The syntax is super clear and succinct, it’s also very DRY and lightweight.
I wrote an article on this approach, you can peruse here. Basically, we write CSS pertaining to type once and only once. We capture those styles in classes and apply them directly to their elements. This approach both saves a lot of time and respects a type system, limiting styles and sizes to classes that have been defined.
We use a variety of expressive classes to speed up development. Everything is written in BEM syntax, this document grows with each project. We’ve found it very useful.
We’re leveraging what’s come to be known as the lobotomized owl selector to handle our vertical spacing needs in templates. Essentially, adding a class of .spacing to a container will generate equal spacing between all of its direct children in the form of top margin. The first child of this container does not get a top-margin, thusly, the spacing is self-contained and contextually aware. We have many permutations of the.spacing class. Where the .spacing class creates 10px of space between elements on small screens, .spacing — half creates 5px pf space between elements and .spacing — double creates 20px.
Our layouts are driven by the Neat Grids framework which sits on top of Bourbon. It’s really the only reason we use Bourbon at this point. Worth noting, we name layout classes by how many columns they have and the percentages that make them up.
for example, is a 2 column layout wherein the first column is 25% and the second is 75%.
- Grunt, a task runner for processing SCSS, image minification (check out our Gruntfile)
- Patternlab to keep our modules super duper portable (not built into this starter file repo)
Hope ya’ll find this helpful. Let us know if you blend any of these techniques into your workflow and if you have feedback, comment below!