Tag Archive: livereload

Posted 01.28.2015

Posted 01.28.2015

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.

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.

NOTE:

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

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:

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.