Happy Cog Starter Files 2016

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.

Peep our public repo here: https://github.com/happycog/templatestarter2016

Here are the main benefits to our approach to CSS.

1. It’s fast.
2. It’s clear.
3. It’s teachable.

In terms of general guidelines, we follow Harry Robert’s 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. .button not .btn and .background not .bg.

Folder structure and file namespacing

Our Sass folder
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.

Breakpoints

We use include media to manage our breakpoints these days. The syntax is super clear and succinct, it’s also very DRY and lightweight.

Expressive Type

Our SCSS file
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.

Tools.scss

Our SCSS file
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.

Vertical spacing

Our SCSS file
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.

Layouts

Our Config file
Our SCSS files
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. .layout-split-2--25-75, for example, is a 2 column layout wherein the first column is 25% and the second is 75%.

Additional tools we leverage:

• Bower, a frontend package manager to manage all javascript plugins
• Grunt, a task runner for processing SCSS, image minification (check out our Gruntfile here)
• 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!

Back to Top