rupl/susy-style-guide — pull request #1 by Snugug (2012-06-01 12:56:30+00:00)
Title: Partial setup

This is a very *very* rough skeleton structure of how I work with partials. We will go over this at 3PM EDT today, but the essence of it is as follows:

* Build out a Global folder with a Base partial to import your Compass extensions, your other Global partials (most commonly Variables, Functions, Mixins, and Extendables), and any styling that will absolutely apply to everything (in our case, natural box model, or cheating at CSS)
* Build out a Style Guide folder which is your site's style guide. In here, there will be a Style-Guide partial, an IE Style-Guide partial, and a Print Style-Guide partial, each of these pulling in the sub partials that they need.
* For Style Guide, sub partials should be put into descriptive folders (fonts, lists, links, etc…) with partials for each set of things being styled (font weights and families, inline lists, link locations, etc…). These should be written as silent extendable classes. Partials that are Print or IE specific should be prefaced with ie. or print.
* The partials that are needed should be imported into each overall partial, and the actual selectors you're going to use should extend off of the relevant silent extendables from the sub partials.
* Build out a Layout folder which will hold all of your site's layout styling. In here, there will be a Layout partial, an IE Layout partial, and a Print Layout partial, each of these pulling in the sub partials that they need.
* For Layout, sub partials should be put into descriptive folders (header, primary_sidebar, content, etc… or ) with partials for each individual item that needs layout (main-nav, search-bar, etc…). These should be written as full selectors. Partials that are Print or IE specific should be prefaced with ie. or print.
* The partials that are needed should be imported into each overall partial. No selectors should be put in these partials, they should only be used for importing.
* Build out a Design folder which will hold all of your site's design styling. In here, there will be a Design partial, an IE Design partial, and a Print Design partial, each of these pulling in the sub partials that they need.
* For Design, sub partials should be put into descriptive folders (header, primary_sidebar, content, etc… or ) with partials for each individual item that needs layout (main-nav, search-bar, etc…). These should be written as full selectors. Partials that are Print or IE specific should be prefaced with ie. or print.
* The partials that are needed should be imported into each overall partial. No selectors should be put in these partials, they should only be used for importing.
* In your root Sass folder, you should have a Style (or Screen) full file, an IE full file, and a Print full file.
* Each of these files will be turned into a full CSS file at compile time.
* Each of these files should import the Base partial first, their named Style Guide partial second, their named Layout partial third, and their named Design partial last.
** No selectors should be written in these files, they are only used for importing.

General Rules of Thumb:
* When writing selectors, write them with the least amount of specificity possible; don't write something that will compile out to ```ul.main-mav li a``` when ```.main-nav a``` will do.
* Unless it is literally the only thing you're selecting that falls under that stack, don't write complex selectors on one line, nest them under their parent element. This provides a better visual indicator as to what you're selecting, is easier to read and debug, and will help provide some sanity to your selectors.
* On a similar note, use the [Inception Rule](http://thesassway.com/beginner/the-inception-rule) when writing nests; never go more than four levels deep!
* Try and make each sub partial in your Layout and Design tree each contain no more than one nest, even if that means a file is 5 lines of code. It's easy, cheap, and a breeze to mentally parse lost of partials that are semantically named and each <30 lines of code as opposed to searching through 1000 or even 100 lines of code. Remember that Sass @import isn't a CSS import, it's a compile time import, so there is no userland slowness.
* If you're trying to do something complex, chances are the Sass community has got your covered. For instance, instead of writing our own code for the fancy Web 2.0-esque glass button for Search, we should use [Sassy Buttons](http://jaredhardy.com/sassy-buttons/).

## MAKE SURE YOU HAVE THE MOST UP TO DATE VERSIONS OF SASS AND SUSY!
```bash
gem install sass --pre
gem install susy --pre
```

I think that's good for a pull request. I'll talk to you at 3EDT!