Sass Articles on the Web

• Sass vs. LESS

  by Chris Coyier, from CSS Tricks, May 2012

• Redesigning with Sass

  by David Walsh, from CSS Tricks, October 2012

• Using Bower with Sass & Compass

  by Anthony Short, October 2012

• Preprocess THIS!

  by Allison Wagner, from Cognition, September 2012

• A Newb’s Guide to Syntactically Awesome Stylesheets (Sass) – part 1

  by Dale Sande, from Unmatched Style, September 2012

• Sass Sleuth: Debugging Sass in Webkit Browsers

  by Roman, from the Mobify blog, August 2012

• Stop the Pain of Vanilla CSS and Get Relief by Adding Toppings with Sass

  by Chris, from the Zurb blog, July 2012

• Building a Nested Responsive Grid with Sass & Compass

  by Trevor Davis, from Viget, May 2012

• Nested Selectors: The Inception Rule

  by Mario 'Kuroir' Ricalde, from The Sass Way, November 2011

• Improve your Responsive Design Workflow with Sass

  by Ryan Taylor, from .net, October 2011

• Getting Started with Sass and Compass

  by Adam Stacoviak, from The Sass Way, June 2011

• Getting Sassy with CSS

  by David Kaneda, from the Sencha blog, June 2010

• Using Compass and Sass for your Next CSS Project

  by Alex Coomans, from Net Tuts, August 2009

• My Media Query Mixin

  by Stuart Robson, April 2013

• Structuring My Sass 101

  by Stuart Robson, January 2013

• Sass doesn't create bad code. Bad coders do.

  by Roy Tomeij, from The Sass Way, February 2012

Contribute

Sass is an open source project and we encourage you to contribute. You can contribute with bug reports and feature requests, and if you contribute code, we'll love you forever. If you just want to help out but you're not sure what to do, the Help Wanted label on the issue tracker is a good place to start. It has a mix of feature requests, bugs, and tasks that aren't coding-intensive that the developers think are a good place for someone new to the codebase to jump in.

When writing code, there are two primary branches we use. The stable branch is the default; is where we do development on the released version of Sass. Bug fixes for released functionality, documentation improvements, and and general infrastructure stuff should all go on stable. The master branch is where we work on the next version of Sass. Once you've followed the steps below, new features should be submitted to master.

The Sass codebase is pretty big, and it can be intimidating to navigate it and understand the best way to make a change. If you need help, make a post on the Sass mailing list; the Sass developers are happy to assist, even if you don't have much experience with Ruby or programming as a whole. They can answer questions about how the system works, suggest avenues for solving problems, and review your code once it's written.

Whether you're adding a feature or fixing a bug, if it changes publicly visible behavior, it's important to write automated tests for it. All the tests live in the test/sass directory; find the test file that's most closely related to your change, and add a test or tests there. For a feature, make sure your tests fully cover all the ways that feature could be used, including ways it could be invalid.

Once you've written a patch with tests, send it to us as a pull request. A developer will look it over, and will probably make some suggestions and requests. Once you address those, it'll get merged in!

Adding Syntax

The biggest and most impressive features of Sass usually involve adding new syntax of some sort. This can be pretty fun—something that used to be an error starts working because you made it—but syntax changes are also a lot of work. For statement-level syntax like a new @-rule, you have to:

• Add a node for the syntax to the abstract syntax tree in lib/sass/tree.

• Parse the syntax in SCSS to the node. The SCSS parser is in lib/sass/scss/parser.rb.

• Parse the syntax in the indented syntax to the node. The indented syntax parser is in lib/sass/engine.rb.

• Add support for setting the compilation options on the node in lib/sass/tree/visitors/set_options.rb.

• Add support for cloning the node in lib/sass/tree/visitors/deep_copy.rb.

• If the syntax is just something new from pure CSS, add support for compiling it to CSS in lib/sass/tree/visitors/to_css.rb. If it's for a Sass feature that's not part of CSS, add runtime behavior in lib/sass/tree/visitors/perform.rb or lib/sass/tree/visitors/cssize.rb.

• Add support for converting the syntax back to SCSS and the indented syntax with sass-convert in lib/sass/tree/visitors/convert.rb. Don't forget to test this conversion, too!