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?
Sass 3.2 is on the way, and there are many improvements to how it handles media queries. Let’s get a jump start on all the new stuff and see how we can use media queries, which are now a first-class citizen, in Sass 3.2.
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.
Those who don’t see any use for pre-processors such as Sass often use the “bad code” argumentation. It creates too specific selectors due to nesting, huge sprites and they hate the way Sass enforces an architectural approach that doesn’t work. And it’s all true. If you’re a poor developer. You know, one who would handcraft too specific selectors, 15MB sprites and doesn’t know how to cleanly structure a project.
What do you get when combine the power of Sass with Zurb? You get Zurb Foundation for Sass and Compass. It’s the perfect flexible grid, desktop to mobile responsive, forms, buttons and UI library, plus other ZURB Playground favorites like Orbit and Reveal.
In part one we talked about how Sass can help with fluid layouts and images. Now we’ll turn our attention to the new kid in town. Media queries are the tool that takes a design from fluid to truly responsive.
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.
The rise in popularity of CSS extensions, such as Sass, in recent years has not gone unnoticed by the people who work on proposing and standardizing modules for CSS3 (and CSS4).