• The answer is: nothing, really.
• You can use SASS (and Compass) on any website. It has nothing to do with Drupal.
• On the Drupal side (in PHP), you'll still be working with compiled CSS files:
• drupal_add_css()
• '#attached' => array('css' => $css)
• stylesheets[] 
• ..."The Drupal Way(s)" still apply

• You're a web developer.
• Web developers generally have to write CSS.
• If you don't, you may want to leave now.
• Web developers generally have a love/hate relationship with CSS.
• If you don't, you may want to leave now.
• Assertion #1: SASS makes CSS approximately 1 billion times better.
• Assertion #2: SASS+Compass makes CSS approximately 1.5 billion times better.
• Proof will be established during this presentation.

// file -> my-first-variable.scss
$color-red: #993434; // hex color is a valid data type
$color-blue: #307aea;
$cdn-prefix: '/dr/ncaa/ncaa7/sites/default/files'; // so is string

body {
  // interpolation syntax - 
  background-image: url('#{$cdn-prefix}/my-image.png'); 
  background-color: $color-red;
  color: $color-blue;
}

// compiles to -> my-first-variable.css
body {
  background-image: url('/dr/ncaa/ncaa7/sites/default/files/my-image.png');  background-color: #993434;
  color: #307aea; }

• Split large stylesheets into smaller, possibly re-usable components (called partials in SASS) that are never directly compiled by themselves.
• Have a common variables partial that gets imported into other stylesheets as needed

 // file -> linescore.scss
 .linescore {
    background-color: purple;
    h2 {
       color: pink;
    }
    a {
       text-decoration: none;
       &:hover {
          text-decoration: underline
       }
    }
 }

@mixin ncaa-nowrap($overflow: 'ellipsis') {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: $overflow;
}

 // file -> article.scss
 // To use a mixin in this file, you must either @import another 
 // *.scss file which defines it OR define it here in this file.
 // Just pretend the mixin resides in 'partials/_toolkit.scss'
 @import 'partials/toolkit'
 p.flow {
    @include ncaa-nowrap();

    &.clip { @include ncaa-nowrap('clip'); }
 }

 // compiles to -> article.css
 p.flow {
   white-space: nowrap;
   overflow: hidden;
   text-overflow: ellipsis; }
 p.flow.clip {   white-space: nowrap;   overflow: hidden;   text-overflow: clip; }

• Functions in SASS are basically what you'd expect.
• They might seem kinda similar to mixins (which are more like macros) at first.
• The difference is that mixins provide one or more style rules and their values.
• Functions are used to compute just a value to be used in a single style rule.
• You can use functions in mixins (but probably not vice-versa AFAIK).

 $color-heading: #4c821c;
 .main-headline {
   color: lighten($color-heading, 15%);
   .sub {
      color: darken($color-heading, 15%);
   }
 }

• All of the cool functionality that SASS brings to the table comes at a cost: the compilation step.
• As you work on *.scss files, before you can see your changes in browser, you'll have to compile all the files you changed.
• Luckily, SASS compilation is quite speedy.
• Furthermore, there are plenty of tools out there to help:
• SASS' own command line utility can compile (obviously) but it can also watch files or folders for changes
• Codekit is a (non-free) GUI for OS X that can watch folders and files and automatically compile them with SASS (among many other things unrelated to SASS)
• Grunt has SASS plugins which can be configured to watch folders etc.

• We don't keep *.css files in source control for custom modules. Hence, our .gitignore files have entries like "css/" and "*.css"
• Why? Because they aren't needed!
• All of our CSS gets compiled at build time from the SASS (ie. right after drush make has run and created "the world").
• We only care to track changes in the SASS, not the compiled output.
• You can write plain CSS into a *.scss file and the compiler will basically leave it alone.
• This makes it easy to transition an existing CSS codebase to SASS piecemeal:
• $ mv some-random.css some-random.scss     # rename it!
• $ sass some-random.scss some-random.css  # compile it! 

• The SASS compiler has different "output style" options.
• This allows us to compile SASS->CSS differently in different environments.
• Eg. In production, we use an output style which minifies the compiled CSS and strips comments.
• There is also a "development-friendly" output style with helpful comments that act as a trace to the origin of the compiled rules (if you use a lot of partials and mixins from other files this is invaluable for debugging):

•  /* line 1, ../compass/arcade.scss */
  .ncaa-arcade {
    position: relative;
    padding: 12px 0;
  }
  

• It is actually possible to configure the contrib Grunt plugin for compiling SASS to do this.
• But it took some doing.
• This gets into some advanced Grunt configuration stuff but I wanted to include it in the deck just because it is a really critical part of our build process.
• Even if it doesn't make 100% sense, just try to remember that it is possible and you can always reach out to us for more information so you don't have to re-solve the problem!
  

• Compass is a SASS framework.
• All plain SASS is valid-Compass SASS but not vice-versa.
• It uses a custom compiler but the same file extension (*.scss)
• The Compass compiler can compile plain SASS that doesn't use any Compass elements but not vice-versa.
• A rough and lazy analogy: Compass:SASS as jQuery:JavaScript
• Our codebase is a mix of plain SASS and Compass SASS *.scss files.
• Each module must choose to be one or the other.
• The rationale is we didn't want to force people to use Compass because it is overkill for many modules. (Or so we thought... turns out >50% of our modules use Compass.)
• We use a simple directory structure/naming convention to differentiate (./compass/*.scss or ./sass/*.scss). More on this later.

• sqrt()
• pi()
• sin()
• cos()
• tan()
• more advanced color manipulation funcs like shade() and tint()
• ... and more that struck me as too esoteric but I guess someone must use them

• Compass includes several utilities that are used outside of the *.scss file
  
• By far the most useful/interesting is "automated spriting"
• No more creating (or worse: updating) sprite maps by hand!
• Never calculate another "background-position" [x,y] coord or sprite cut size
• Simply:
• Drop individual cuts into a folder within your module.
• Use the Compass sprite utility to automatically generate the sprite map image + a partial with mixins to provide CSS rules.
• Makes maintaining and altering existing sprite maps infinitely quicker.
• If there is time: live_data (REAL WORLD PROD example)

• As I mentioned before, we use a simple directory structure to differentiate between modules that use Compass and modules that don't (ie. those that just use plain SASS)
• In our world, a module must choose to either be a Compass module or a SASS module. This is to aid build automation but it also keeps things simpler for developers. It gives them an at-a-glance way of seeing what the module uses for its stylesheets. 
• Our build tools know how to differentiate between the two, and will use the appropriate compiler.
• (Yes, the Compass compiler could technically do everything but, again, it is kind of slow so we like to use the SASS compiler wherever possible.)