autoprefixer bem codekit grunt gulp livereload sass smacss style guide

My Sass(y) Pants | Self Teach . Me : Self Teach . Me

There’s been lots of speak just lately about SASS and CSS structure and Type Guides. It’s sort of cool, really, to see front-end take the “front stage.”

I assumed I’d add my two cents and pull back the curtain somewhat bit. Or…watch this video and mentally exchange “tight pants” with “Sassy pants.”

Jokes.


Preprocessing

Yes, please.

NOTE:

Your browser can’t truly learn Sass. Stunned? Your browser can solely read CSS. In the event you’re writing Sass, you want a preprocessor to translate your code from Sass to CSS.

Consider it this manner a preprocessor, processes your code earlier than (pre) you add it to your server.

Preprocessors aren’t simply limited to compiling Sass to CSS. They will do loads of different issues, like scale back your picture measurement, rename information, build sprites. They’re pretty superior.

To me, a preprocessor, is a no brainer. Any software that’s going to make my job simpler, sign me up!

I’ve tried several.

Before I began writing Sass, I began with LESS, just because I might put their much less.js on the server and never worry about compiling. Their JavaScript file dealt with the whole lot for me. Granted, this isn’t best, COUGH sleek degradation.

Then, I began wanting into Sass. I used to be interested by what Sass had to supply because it appeared more widespread and to have extra options. On the time, I used to be operating an older version of MacOS that wasn’t supported by CodeKit. So, I turned to LiveReLoad.

Once I did upgrade, CodeKit was one of the first things I installed. I LOVED CodeKit…until I started working on a larger undertaking that took a minute plus to compile. In all fairness, I don’t assume it was CodeKit’s fault. Compass constructing sprites and RubySASS have been in all probability the culprits.

Regardless, it pressured me to show to grunt and then finally, to gulp as options — And gulp, I shall stay (for now).

The great half about this development is that it allowed me to experiment with quite a lot of tools. Once I’m collaborating with one other developer, I’m in a position to use whatever technique they’ve already put into place.


Prefixing

I used to depend on Compass for prefixing, but Autoprefixer is superior. The most effective half is that it makes use of the newest knowledge from Can I Use to add only the required vendor prefixes.


Organization of Information

I maintain all my pictures, fonts, sass, css, and javascript information in an belongings folder. They are separated into 2 subdirectories, dist for distributed, compiled information, and src for supply, unique information.

Asset Folder Organization

Again in the day, once I used to write down lengthy type css by hand, I might listing my redefined types at the prime: p, a, hr, you get the thought. Then, format specific types, items I might use on multiple pages, and eventually web page specific types. This made sense from a cascading standpoint.

I’ve tried to take care of an analogous construction for my SCSS information:

  • _1_base
    This incorporates Zurb Foundation overrides and WordPress particular types
  • _2_helpers
    These are features, extends, mixins, variables, and theme information
  • _3_vendor
    Any third get together types I need to incorporate: fonts, icomoon, and so on.
  • _4_redefine
    Begin to look acquainted now? These are the redefined types that I discussed earlier.
  • _5_layout
    Format particular types
  • _6_pieces
    Pieces that I’ll reuse in multiple locations (like social media icons)
  • _7_pages
    Web page particular information.

Inside each folder, there’s a file with an identical identify as the folder (within _7_pages, there’s a _pages.scss file. It lists out all the opposite information inside that listing to incorporate:

@import “home”;
@import “blog”;
@import “clients”;
@import “ebooks”;
@import “coaching”;
@import “podcast”;
@import “speaking”;
@import “contact”;

Inside the primary scss folder, there’s a most important.scss that imports Basis 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/format”;
@import “_6_pieces/items”;
@import “_7_pages/pages”;

This implies all my SASS will get compiled into 1 giant CSS file. If I do end up having multiple CSS information, it’s to account for IE particular types.

All my partial information are prefixed with an underscore.


Naming Conventions

Should you didn’t know, naming CSS stuff is basically exhausting. Plenty of actually sensible individuals, individuals much smarter than me, debate about this stuff. There appears to be two important camps: BEM and SMACCS.

BEM stands for block, factor, modifier.

SMACSS stands for Scalable and Modular Structure for CSS

I do know, much more alphabet soup so as to add to the equation!

Once I started making an attempt to determine my tips, cssguidelin.es turned a terrific useful resource. There’s a piece there on BEM-like naming conventions.

The fastest method to describe it: nested parts have double underscores:

.social-media__icons

.social-media__text

You don’t need to repeat the DOM in your CSS, however you do need to make it easier to determine.

Modifiers or statuses have double dashes:

.social-media-—giant

You may as well tell from my instance that a number of phrases will not be camel cased, but moderately have a single sprint between every phrase.

NOTE:

SASS truly makes one of these naming very easy:
.social-media
&__icons
&__text
&—-large

Renders:

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


Extendable Courses

Once I’m writing courses I do know I need to prolong, I’ll prepend the category identify with a %.

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

There are several advantages here:

  1. The class doesn’t truly get written until it’s used. So, I’ve been capable of create a small library of parts which might be obtainable to me in all my tasks.
  2. The % signifies it’s was meant to be extended and is being used in a number of places. Reminding me to not change the fashion, until I need to danger changing other parts that also depend on it.

Courses vs IDs

I attempt to use courses as an alternative of IDs. The primary cause is due to specificity. You need your code to be as reusable as potential and all your ID parts ought to be distinctive.

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

Naming Variables

All my colors are stored in variables:

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

Once I’m naming grays, as an alternative of making an attempt to recollect the distinction between $dark-gray, $darker-gray, and $darkest-gray, I identify them by the first letter / number in their hex value: $gray-a, $gray-Eight, or $gray-c.

All my font names are saved as variables. For those who’ve used TypeKit, fonts.com, or Google Fonts, you’ll know typically it’s arduous to recollect the precise syntax for a font identify. So, storing these values inside a variable makes this a no brainer.

I’ll attempt to abstract this even additional by making a _themes.scss file. I’ll write an extendable courses with a more generic identify:

%body
font-family: $dagny;

%sans-serif
font-family: $brandon;
text-transform: uppercase;

%serif
font-family: $adelle;

Now, if a shopper needs to vary the font, this turns into really easy. As an alternative of finding and changing all my $dagny variables, I simply, change the typeface within my %body definition.

The identical concept extends to colors:

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

Once I’m defining the typography, I’ll write an extendable class after which embrace it:

%h1
@prolong %sans-serif;
font-size: emCalc(72px); /* emCalc() is Basis perform */

h1
@prolong %h1;

Separating it out that means, helps me do issues like this easily:

.page-title
@prolong %h1;

Tabs vs. Areas

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

I choose tabs. I identical to seeing the additional area.

CSS Rule Units

  • I’ve one selector per line. The primary purpose is that it makes git commits much more meaningful. Plus, it means the display width of my scss file isn’t very large. I can hold it in a second pane within Chic with out sacrificing to much of my display.
  • 1 area earlier than the opening curly bracket
  • A line break after the opening curly brace
  • No area earlier than the colon
  • 1 area after the colon
  • No area earlier than the semi-colon
  • A line break after the semi colon. (this wasn’t all the time the case)
  • No area 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. However, if they’re not associated, they’ll have 5 clean strains between.

SASSY things

I attempt to persist with the following order of properties:

  1. @prolong
  2. @consists of
  3. Common property values (in alphabetical order)
  4. Pseudo component nesting
  5. Common component nesting
  6. Media queries

I know the alphabetical order factor sounds dumb, nevertheless it actually does help once you’re skimming for a selected property.

Nesting

I attempt not to nest. I’m not all the time great at respecting that rule. SASS just makes it means too straightforward to nest.

Feedback

On the prime of every file, I’ve a remark labeling the file:

/*————————————*

/*————————————*/

The # is meant to make it straightforward to seek out inside the undertaking.

Sprites

I have an excellent SVG sprite system set up.

NOTE:

I initially began with Compass. It labored nice, however I used to be having to create a number of sprite sheets to account for retina, an icon may need a number of versions inside one sheet to account for the varied sizes, and on larger tasks, it’d take some time to render out.

Then, I discovered icomoon. It was nice as a result of it handled plenty of the problems I found with Compass. I was capable of resize icons on the fly, change colours on the fly, and it minimize down on my render time. Nevertheless, each time I needed to make a change, I had to go to the icomoon website, add the brand new icon, download the new information, and exchange my present information.

Enter SVG sprites

Then, as soon as I obtained a setup for SVG sprites, all this stuff magically fell into place.

Unicorn

Just kidding.

Within my src / img / svg folder, I’ll save all my exported svgs. Then, gulp will deal with the remaining. Superior!

Different Fashion Guides

I’ve compiled a brief record of a few of the different “style guides” I’ve read on the Web:

Further Assets

  • styleguides.io – This can be a implausible useful resource that compiles type guides and elegance information info from everywhere in the inter webs.
  • cssguidelin.es – I know I mentioned it earlier, however critically, take a look at this website and take the time to learn it. It undoubtedly helped me.

Sassy Pants

In the Comments

How do you structure your type sheets?