Sass has an awesome community of designers and developers who love to spread the word and help people out. Here we’ve collected some resources. Happy Styling!
Everyone is welcome in the Sass community, except those who are unwelcoming. Please read and follow our community guidelines.
Still getting started? There are some great tutorials out there to get you on your feet. Want to learn more? There's some great Sass blogs (including a few particular articles we recommend reading), and even a few books about Sass to help you learn some new tips and tricks.
Thinking of contributing to Sass itself? We rely on everyone to keep Sass as stable as it is. Feel free to submit a patch via pull request to the Sass project.
Want to create your own Sass implementation? Check out our implementation guidelines.
Sass Articles on the Web
by Chris Coyier, from CSS Tricks, May 2012
by David Walsh, from CSS Tricks, October 2012
by Anthony Short, October 2012
by Allison Wagner, from Cognition, September 2012
by Dale Sande, from Unmatched Style, September 2012
by Roman, from the Mobify blog, August 2012
by Chris, from the Zurb blog, July 2012
by Trevor Davis, from Viget, May 2012
by Mario 'Kuroir' Ricalde, from The Sass Way, November 2011
by Ryan Taylor, from .net, October 2011
by Adam Stacoviak, from The Sass Way, June 2011
by David Kaneda, from the Sencha blog, June 2010
by Alex Coomans, from Net Tuts, August 2009
by Stuart Robson, April 2013
by Stuart Robson, January 2013
by Roy Tomeij, from The Sass Way, February 2012
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; it 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 in the stable branch. 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!
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
Parse the syntax in SCSS to the node. The SCSS parser is in
Parse the syntax in the indented syntax to the node. The indented syntax parser is in
Add support for setting the compilation options on the node in
Add support for cloning the node in
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
Add support for converting the syntax back to SCSS and the indented syntax with
lib/sass/tree/visitors/convert.rb. Don't forget to test this conversion, too!
- The Sass Way
- Ben Frain
- Viget Inspire
- Unmatched Style
- Sass Bites
- Sass News Weekly
- Sass in the Real World: book 1 of 4
- Sass in the Real World: book 2 of 4
- Sass for Web Designers (Nov 2013)
- Sass and Compass in Action (Aug 2013)
- Sass and Compass for Designers (April 2013)
- Pragmatic Guide to Sass (Dec 2011)
Projects & Frameworks
- libSass — a CSS (and Sass!) authoring framework
- Compass — a CSS (and Sass!) authoring framework
- Susy — a responsive grid layout built for Compass
- Bourbon — a lightweight mixin library
- Neat — a mixin-based grid layout system
- Sache — a place to find Sass and Compass extensions
- SassMeister — a tool for trying Sass in the browser
- Zurb Foundation — a responsive front-end framework
- Rock Hammer — a starting framework with some basic styles for a project
- Bootstrap — the ubiquitous framework… this time written in Sass!
- Gravity — a framework for making HTML5 websites with Sass
- Inuit.css — a powerful, scalable, Sass-based, BEM, OOCSS framework
- flexiblegs — Flexible Grid System
- SassDoc — A documentation tool for Sass
- SassMe — Visualize Sass color function output in real-time — no compiling!