Posted 01.28.2015

My SASS(y Pants)

logo-235e394c

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.”

Jokes.


Preprocessing

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.


Prefixing

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, cssguidelin.es 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.

NOTE:

SASS actually makes this type of naming really easy:

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

Renders:

.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 fonts.com 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.


Nesting

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


Comments

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

/*------------------------------------*\

VARIABLES

/*------------------------------------*/

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


Sprites

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

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

sassy_pants

In the Comments

How do you structure your style sheets?