CSS

Learn how to use Sass color functions to calculate backwards compatible colors for browsers that don't support alpha transparency and wrap up this functionality in a couple of handy mixins.

Learn how to modularize your typography to create solid foundation for your projects. Use multiple classes and the @extend directive to create a reusable set of typographical styles.

The more you write your own stylesheets, the more you begin to value using good names in your code. Naming is by far one of the most difficult and debated activities of a developer. To many, naming is an art form.

If avoiding nested selectors in favor of a flatter class-based CSS scares you, maybe this example will help you embrace some of the principles of modular CSS.

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?

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?

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 ...