Posted 02.03.2015

Posted 02.03.2015

My SASS Extends, Mixins, and Functions

Last week, I wrote a little post about the SASS I have running on my site. Continuing on, I thought I’d share my SASS broilerplate with some of the mixins, functions, and extends.

Naming Breakpoints

In my SASS breakpoints file, I’m using Chris Coyier’s Breakpoint trick. — It’s a mixin within _2_helpers / _breakpoints.scss file. It takes a break point name and builds out the media query for me.

@mixin breakpoint($point) 		{
	@if $point == zurb-xxlarge {
		@media (max-width: 1921px) { @content; }
	@if $point == large-screen {
		@media (max-width: 1600px) { @content; }
	@if $point == zurb-xlarge {
		@media (max-width: 1441px) { @content; }
	@else if $point == retina {
		@media (-webkit-min-device-pixel-ratio: 2), screen and (max--moz-device-pixel-ratio: 2) { @content; }
	@else if $point == regular-screen {
		@media (max-width: 1250px) { @content; }
  	@else if $point ==  zurb-medium {
		@media (max-width: 1024px)  { @content; }
	@else if $point ==  smaller-screen {
		@media (max-width: 800px)  { @content; }
	@else if $point ==  ipad-portrait {
		@media (max-width: 768px)  { @content; }
	@else if $point ==  zurb-small {
		@media (max-width: 640px)  { @content; }
	@else if $point ==  iphone-four {
		@media (max-width: 360px)  { @content; }
	@else if $point ==  iphone {
		@media (max-width: 320px)  { @content; }

I name my breakpoints according to the device (I know. I know.) I’m using: ipad-landscape, ipad-portrait, smaller-screen, iphone. I know the world exists outside of Apple and we are becoming (if not there already) device independent. However, I think in those dimensions.

I also have breakpoints for zurb-medium and zurb-small. I use the Zurb Foundation framework and those breakpoints already exist within the framework. Since, the grid is already collapsing at those points, I need to be able to make adjustments in my code as well.

When I want to implement these breakpoints within my SASS, it will look like this:

.something {
	padding: 100px;

	@include breakpoint(zurb-small) {
		padding: 10px;

I have a snippet set up Sublime Text 3 that makes this really easy to implement.


On CSS-Tricks, there’s a post about creating triangles in pure CSS. I decided to turn that into a mixin.

@mixin arrow ($direction, $size, $color) {
	@if $direction == up {
		border-left: $size solid transparent;
		border-right: $size solid transparent;
		border-bottom: $size solid $color;
	} @else if $direction == down {
		border-left: $size solid transparent;
		border-right: $size solid transparent;
		border-top: $size solid $color;
	} @else if $direction == right {
		border-top: $size solid transparent;
		border-bottom: $size solid transparent;
		border-left: $size solid $color;
	} @else if $direction == left {
		border-top: $size solid transparent;
		border-bottom: $size solid transparent;
		border-right:$size solid $color;

Then, when I want to implement it:

.read-more { 
		&:before {
			@include arrow (right, 3px, black);

That’s easy enough.


I have a set of functions for dealing with color:

@function darkest( $color ) 	{ @return darken($color,20%); }
@function darker( $color ) 		{ @return darken($color,13.333%); }
@function dark( $color ) 		{ @return darken($color,6.667%); }
@function light( $color ) 		{ @return lighten($color,16.667%); }
@function lighter( $color ) 	{ @return lighten($color,33.333%); }
@function lightest( $color ) 	{ @return lighten($color,50%); }

I can easily make the rollover color, a shade darker by using:

a {
	&:hover {
		color: darker($red);

I don’t have to open Photoshop or create an additional variable.

Black and White (and Color)

%black-and-white {
	filter: grayscale(100%);

%color {
	filter: grayscale(0%);

Now, I can easily convert anything to black and white:

.my-image {
	@extend %black-and-white;

Then, if I want to give it color, say on rollover:

.my-image {
		&:hover {
			@extend %color;


@mixin columns ($columns: 2, $gap: 90px) {
	column-count: $columns;
	column-gap: $gap;

This mixin makes it easy to implement columns. You can tell from the code that I have defaults set for 2 columns with 90px between each column. Meaning, I can implement it without adding any parameters:

.two-columns {
	@include columns();

Or if I want to over ride it I can:

.three-columns {
		@include columns(3, 30px);

If I want to get crazy, I can even use some of my mixins together:

.two-columns {
	@include columns();

	@include breakpoint(zurb-small) {
		@include columns(1);

This just says that the two column class will display 2 columns, unless we’re on mobile. Then, display 1 column.


I have a path function that makes it easy to include images within my SCSS:

@function path($src, $dir: img) {
	$src: unquote($src);
	@return url(unquote("..")/$dir/$src);

When I set a background image, it might look like this:

.background-image {
	background: path("my-background-image.jpg") center top no-repeat;

By default, it puts my images within a img directory. I can override that, either by passing in another parameter or adjusting the function.


.left {
	float: left;

%right {
	float: right;

.text--left {
	text-align: left;

.text--right {
	 text-align: right;

.text--center {
	text-align: center;
	width: 100%;

Tehse are a few alignment classes that make it easy to knock something left, right, or center. You’ll notice I have an extends (%) as well as the class (.) that way I can use these classes on the within my HTML as well.

List Styling

%no-bullets {
	list-style: none;

This is great when I’m working on site navigation:

nav ul {
	@extend %no-bullets;

No Margin, No Padding

%no-margin-padding {
		margin: 0;
		padding: 0;

Just as the name suggests, using this will remove any margin and padding from the element:

nav ul {
	@extend %no-margin-padding;


%circle {
	border-radius: 50em;

This turns any item into a circle:

.circle-thumbnail {
		@extend %circle;


These are all great, but what’s the point? Well, instead of having to write these styles everytime I sit down to work on a project, I have a starting point. Don’t reinvent the wheel every time if you don’t have to. Make it easier on yourself!

Second, any project that I work on, I know I have certain classes available to me. I don’t have to look up the class names. I’ve established a set of standards. Remember, smarter not harder.

Posted 01.28.2015

My SASS(y Pants)


There’s been a lot of talk recently about SASS and CSS structure and Style Guides. It’s kind of cool, really, to see front-end take the “front stage.”

I thought I’d add my two cents and pull back the curtain a little bit. Or…watch this video and replace “tight pants” with “SASSy pants.”



Yes, please.

To me this is a no brainer. Any tool that is going to make my job easier, sign me up!

I’ve run the gamut on these.

I started with LESS because I could put less.js on the server and not worry about compiling. Granted, this isn’t ideal, COUGH graceful degradion.

Then, I started looking into SASS. I was curious because it seemed to be more popular and have more features. At the time, I was running an older verison of MacOS that wasn’t supported by CodeKit. So, I turned to LiveReLoad.

When I did upgrade, though, CodeKit was one of the first things I installed. I LOVED CodeKit…until I started working on a larger project that took a minute plus to compile. In all fairness, I don’t think it was CodeKit’s fault. It was probably the result of Compass building sprites and RubySASS.

Regardless, it forced me to turn to grunt and then finally, to gulp. — And gulp, I shall remain (for now).

The good part about this progression is that it allowed me to experiment with a variety of tools. When I’m collaborating with another developer, I’m able to use whatever method they’ve already put into place.


I used to rely on Compass for prefixing, but Autoprefixer is awesome. The best part is that it utilizes the most recent data from Can I Use to add only the necessary vendor prefixes.

Organization of Files

I keep all my images, fonts, sass, css, and javascript files in an assets folder. They are separated into 2 subdirectories, dist for distributed, compiled files, and src for source, original files.

Screen Shot 2015-01-28 at 8.58.04 PM

Back in the day, when I used to write long form css by hand, I would list my redefined styles at the top: p, a, hr, you get the idea. Then, layout specific styles, pieces I would use on multiple pages, and finally page specific styles. This made sense from a cascading standpoint.

I’ve tried to maintain a similar structure for my SCSS files:

  • _1_base This contains Zurb Foundation overrides and WordPress specific styles
  • _2_helpers These are functions, extends, mixins, variables, and thene files
  • _3_vendor Any third party styles I want to incorporate: fonts, icomoon, etc.
  • _4_redefine Start to lok familiar now? These are the redefined styles that I mentioned earlier.
  • _5_layout Layout specific styles
  • _6_pieces Pieces that I’ll reuse in multiple places (like social media icons)
  • _7_pages Page specific files.

Within each folder, there’s a file with a similar name as the folder (within _7_pages, there’s a _pages.scss file. It lists out all the other files within that directory to include:

@import "home";
@import "blog";
@import "clients";
@import "ebooks";
@import "coaching";
@import "podcast";
@import "speaking";
@import "contact";

Within the main scss folder, there’s a main.scss that imports Foundation and each folder’s “index” file:

@import “_1_base/base";
@import “_2_helpers/helpers";
@import “_3_vendor/vendor";
@import “_4_redefine/redefine";
@import “_5_layout/layout";
@import “_6_pieces/pieces";
@import “_7_pages/pages";

This means all my SASS gets compiled into 1 large CSS file. If I do end up having multiple CSS files, it’s to account for IE specific styles.

All my partial files are prefixed with an underscore.

Naming Conventions

If you didn’t know, naming CSS stuff is really hard. Plenty of really smart people, people much smarter than me debate about these things. There seems to be two main camps: BEM and SMACCS.

BEM stands for block, element, modifier.

SMACSS stands for Scalable and Modular Architecture for CSS

A lot more alphabet soup to add to the equation!

When I started trying to figure out my guidelines, became a terrific resource. There’s a section there on BEM-like naming conventions.

The fastest way to describe it is nested elements have double underscores:

.social-media__icons {}

.social-media__text {}

You don’t want to repeat the DOM in your CSS, but you do want to make it easier to identify.

Modifiers or statuses have double dashes:

.social-media-—large {}

You can also tell from my example that multiple words are not camel cased, but rather have a single dash between each word.


SASS actually makes this type of naming really easy:

.social-media {
    &__icons {}
    &__text {}
    &—-large {}


.social-media {}
.social-media__icons {}
.social-media__text {}
.social-media—-large {}

Extendable Classes

When I’m writing classes I know I want to extend, I’ll prepend the class name with a %.

%no-margin-padding {
     margin: 0;
     padding: 0;

There are several advantages here: (1) The class doesn’t actually get written unless it’s used. So, I’ve been able to create a small library of elements that are available to me in all my projects. (2) The % signifies it’s was meant to be extended and is being used in multiple places = don’t change it unless you want it to risk changing multiple elements across the board.

Classes vs IDs

I try to use classes instead of IDs. The main reason is because of specificity. You want your code to be as reusable as possible and all your ID elements should be unique.

If I’m using JavaScript to hook on to a particular element, I’ll add an addition class, prepended with js-. This lets me know later that JavaScript is using that particular tag, so don’t change it!

Naming Variables

All my colors are stored in variables:

$brown     : #847b6c;
$green     : #35b774;
$sky-blue    : #5ecbea;
$teal     : #3a6a77;

When I’m naming grays, instead of trying to remember the difference between $dark-gray, $darker-gray, and $darkest-gray, I name them by the first letter / number in their hex value: $gray-a, $gray-8, or $gray-c.

All my font names are stored as variables. If you’ve used or Google Fonts, you’ll know sometimes it’s hard to remember the exact syntax for a font name. So, storing these values within a variable makes this a no-brainer.

I’ll try and abstract this even further by creating a _themes.scss file. I’ll write an extendable classes with a more generic name:

%body { font-family: $dagny; } %sans-serif { font-family: $brandon; text-transform: uppercase; } %serif { font-family: $adelle; }

Now, if a client wants to change the font, this becomes really easy. Instead of finding and replacing all my $dagny variables, I simply, change the typeface within my %body definition.

The same concept extends to colors:

$border-color : $gray-c;
$heading-color : $red;

When I’m defining the typography, I’ll write an extendable class and then include it:

%h1 {
    @extend %sans-serif;
    font-size: emCalc(72px); /* emCalc() is Foundation function */

h1 {
    @extend %h1;

Separating it out that way, helps me do things like this easily:

.page-title { @extend %h1; }

Tabs vs. Spaces

I know I will be judged here. It’s OK, go ahead pull out your stones.

I prefer tabs. I just like seeing the extra space.

CSS Rule Sets

  • I have one selector per line. The main reason is that it makes git commits far more meaningful. Plus, it means the display width of my scss file is not very wide. I can keep it in a second pane within Sublime without sacrificing to much of my screen.
  • 1 space before the opening curly bracket {
  • A line break after the opening curly brace
  • No space before the colon
  • 1 space after the colon
  • No space before the semi-colon
  • A line break after the semi colon. (this wasn’t always the case)
  • No space before the closing curly bracket }
  • Put the closing curly bracket on its own line
  • A line break after the closing curly bracket
  • Most properties have 1 blank line between them. But, if they’re not related, they’ll have 5 blank lines between.

SASSY things

I try to stick to the following order of properties:

  • @extend

    • @includes
    • Regular property values (in alphabetical order)
    • Pseudo element nesting
    • Regular element nesting
    • Media queries

I know the alphabetical order thing sounds dumb, but it really does help when you’re skimming for a specific property.


I try not to nest. I’m not always great at it, though. SASS just makes it way too easy.


At the top of every file, I have a comment labeling the file:




The # is supposed to make it easy to find within the project.


I’ve finally moved to an SVG spriting system.

Let me describe a little bit of the history, here. I originally started with Compass. It worked great, but I was having to create multiple sprite sheets to account for retina, an icon might have multiple versions within one sheet to account for the various sizes, and on larger projects, it’d take a while to render out.

Then, I discovered icomoon. It was great because it handled a lot of the problems I found with Compass. I was able to resize icons on the fly, change colors on the fly, and it cut down on my render time. However, every time I wanted to make a change, I had to visit the icomoon site, upload the new icon, download the new files, and replace my existing files.

Then, once I got a setup for SVG sprites, all these things magically fell into place.

<Insert picture of the unicorn here> Just kidding.

Within my src / img / svg folder, I’ll save all my exported svgs. Then, gulp will handle the rest. Awesome!

Other Style Guides

I’ve compiled a short list of some of the other “style guides” I’ve read on the Internet:

Additional Resources

  • – This is a fantastic resource that compiles style guides and style guide information from all over the inter webs.
  • – I know I mentioned it earlier, but seriously, check out this site and take the time to read it. It definitely helped me.


In the Comments

How do you structure your style sheets?

Posted 01.07.2015

The Lazy Smart Programmer’s way to set up a WordPress Site


When you get ready to set up a WordPress site, typically your process looks something like this:

  1. Download the latest version of WordPress from
  2. Unzip it.
  3. Copy and paste the files into a local directory (you are developing locally, right?)
  4. Create a MySQL database.
  5. Run the 5 minute WordPress install.
  6. Download your starter theme.
  7. Unzip it.
  8. Copy and paste the theme file into WordPress’s theme directory.
  9. Find your base plugins that you know you’ll need. Download each of them individually.
  10. Copy and paste the plugin files into WordPress’s plugin directory.
  11. Start your custom work.

That’s 11 steps, at least! I know, if you do it enough times you could probably get that down to a 15 minute setup, and that’s probably only if you have local versions of your boilerplate theme and plugins that you can quickly copy and paste into the respective directories.

But, why? Why would you even want to waste your time doing such mindless work every time you start a project when you could be spending that time designing and developing something beautiful and original?

What if I were to tell you that you could cut down that down to two minutes…on a bad day? Interested?

If you can hang with me for the length of this post, we can get you set up and you can start being more efficient.

Remember in English class, how they told us to (1) say what you’re going to say, (2) say it, and then (3) say what you said. I always remember thinking, “That sounds redundant.” Well, I’m going to take a lesson from Mrs. Nooks. I’ll tell you a little bit about the tools we’re going to put in our tool chest, then I’ll show you practically how to use them. It may get a little technical from time to time, but try to stick with it, it will be worth it.


A lot of services are built on Node.js. If you visit the Node.js site it says it’s built on Chrome’s JavaScript runtime. Just know, that means f-a-s-t.

If we’re going to use it, we have to install it. Fortunately for us, this is easy. There’s a big green “install” button their site. Click it.


Once the package is downloaded, unzip, and double click on the package to install it. Hooray!

Node successfully installed!


Grunt and Gulp also run on Node. (Blog post for the future.) Just know, for now, we’re set up for success!



Yeoman is a project generator. It can do quite a bit, setting up sites and scaffolding (and not just for WordPress). We’re going to take the easy way out and use a generator Wesley Todd has already created specifically for starting a WordPress project: YeoPress.


To run YeoPress, Node is the only thing that is required (which we just installed), however, Wesley encourages you to have git and SASS installed, too. If you don’t, no worries, it’s pretty straightforward too:


You can go to the git website, download the file, unzip, and double click on the package to install it. Done and done.


SASS is a Ruby gem. If you’re working on a Mac, it comes with Ruby already installed. All you have to do is open up your Terminal (GASP I know, it will be OK.) and run the command:

gem install sass

If you get an error, chances are you need to run the sudo command:

sudo gem install sass

Sudo forces your computer to run the command. It will ask you to enter your computer’s password.

If you want to check to make sure everything was installed correctly, you can run:

sass -v

You should see it return Sass 3.4.9 (Selective Steve).

Now, for installing Yeoman (yo) and YeoPress (at the same time). Within the Terminal run:

npm install -g yo generator-wordpress

npm just means that it’s a node command.


Now, within the Terminal, we just have to navigate to the folder we want to install WordPress inside of.

If I lost you at, “within the Terminal,” it’s OK.

For the longest time, I was uncomfortable inside the Terminal, too. But, I promise, the more you use the more comfortable you’ll become. As soon as you see the benefits that the Terminal provides your workflow, it will eventually become something you can’t / won’t want to ignore.

You can get started with the Terminal here.

Now, run:

yo wordpress

You’ll see the WordPress logo appear and it will start to ask you a series of questions about how you want to set up your WordPress install:

WordPress URL
If you’re doing local development (as you should), enter that URL in.

Running yo wordpress within the Terminal

Table Prefix
This is the table prefix for your WordPress database. By default it’s wp_. Stay with that. It makes it easy when you’re looking at your database to be able to tell which tables are related to your WordPress install.

Table prefix when running yo WordPress within the Terminal

Database Host, Name, User, Password

Entering Database credentials when running yo wordpress

I use a free app on my Mac, called Sequel Pro to manage my databases. But, if you’re using MAMP, you can do everything through PHPMyAdmin.

MAMP will also list all the credentials you need (host, user, and password) on the WebStart page.

Webstart Screen in MAMP

Use Git?
More on this later, too, but for now, take my word and just say “Yes”…err, rather “Y”.

use git inside yo wordpress

Would you like to install WordPress as a submodule?

There are people that sit on both sides of the fence on this one, people for and against.

My personal take?

First, let me explain what a submodule is. Submodules are a “Git thing”. It’s essentially an external Git repo that your repo references. Think of it as a nested repo that you can update it independently.

When you think of it in those terms, it makes sense to implement WordPress as a submodule. I don’t manage the WordPress core, so why not make it seperate and reference the actual WordPress repo itself?

If you implement WordPress as a submodule, you’ll using the following commands to update WordPress later:

cd wp
git fetch && git fetch –tags
git checkout 4.1
cd ..
git add wp
git commit -m “Updated to WP 4.1”
git push

Not too shabby.


If you get an error, when you try to update WordPress, like: Your local changes to the following files would be overwritten by checkout. Try forcing the checkout:

git checkout -f another-branch

So… “Yes” install WordPress as a submodule.

Wordpress as a submodule

WordPress install directory
My personal preference is “wp.”

This means when I log in to the admin panel, the address will be:

WordPress content directory
I go with “wp-content.”

Directories for WordPress Install

Install a custom theme?
I choose “no.” But, I think this would be a good area, in the future, to streamline my process even more.

Does this all look correct?
It’s always comforting that it asks you to double check. “Yes.”

yo wordpress - all correct?

Boom! It will download WordPress for you and set up your config file. Granted, the set up may sound a little verbose, but we just condensed that 11 step process into a few lines of code.

For future reference:

If you clone your repo and the wp directory is blank (WordPress is a submodule, remember), run:

git submodule init && git submodule update

Also, if you need to update YeoPress, it’s as simple as running the following line:

npm update -g yo generator-wordpress