We’ve written before about the dangers of nesting your CSS selectors too deeply. The Inception Rule is a good one for getting you to avoid some mangled CSS selectors. But there’s actually a lot of benefit to taking this concept a couple of steps farther. What happens when you avoid nesting for almost all of your major selectors?
John W. Long
Managing Editor / UX Designer
One of the coolest features of crafting CSS with Sass is that you can build out a file structure that puts all your components in their right place. BUT the question is … where is the right place? Is there a standard way to structure your Sass files?
One part suggestion to the Sass community to adopt a standard way of structuring Sass modules and one part show and tell. John attempts to leverage his knowledge of large Sass projects to suggest a format for a Standard Module Definition for Sass.
Most people who use Sass are familiar to some degree with the command line. While programs like Compass.app and Scout.app are making it easier to use Sass and Compass without using the command line, hidden gems await those who are willing to do so.
Since the creation of Sass, it has been plagued by many levels of controversy. It billed itself as “a better CSS” and added brand new features unheard of to CSS authors such as variables, nesting and mixins. Sass also introduced an entirely different indentation-oriented syntax and a brand new perspective on how to author CSS. Then the SCSS syntax (Sassy CSS) was introduced …
Without question, one of the most powerful and valuable features of Sass is the ability to package up existing code into reusable chunks of code called mixins.