We've been using Sass here at ZURB for many years. In fact, Foundation has had Sass integration since version 2.1, all the way back in 2011! Preprocessors have changed quite a bit since then, but one thing has always stayed constant: they make writing CSS fast and flexible.
We pass this speed and flexibility onto our Foundation users though Sass variables, mixins, and functions. However, every tool has its strengths and weaknesses. As we mentioned in our Foundation 6 announcement, we've been rethinking every aspect of the framework, including closely examining when and where to use Sass. These changes will make the framework faster to learn and easier to use for you, the developer.
The Bottom Line
Yep, let's start with the bottom line: when writing Sass, remember that you're always one step removed from your CSS output. In general, we shouldn't be producing crazy CSS that we would never write without Sass.
Now let's take a closer look using three specific examples.
Example #1: Nesting and Specificity
Specificity tells us how competing CSS selectors will decide which rules get applied to an element. In general, we want to write the least specific selectors possible, so our rules have less chance of conflicting with other rules we write down the road.
Nesting is the signature feature of Sass, but if you nest too much, your CSS will become needlessly complex. Nesting makes it easy to write CSS that matches the structure of your HTML, but just because one element goes inside another, doesn't mean your CSS rules need to also.
Here's a basic example of your stock <ul> navigation, with <li>'s and <a>'s.
The innermost rule applies only to <a>'s inside <li>'s inside a .menu element. But wait— in this pattern, <a> will always be inside <li> , making that qualification unnecessary. We can simplify our Sass— and our final CSS— with this change:
Now our innermost selector is one tag less specific, making our code more maintainable in the long run.
Example #2: Looping
Looping is an awesome feature of Sass which allows us to generate a lot of CSS with very few lines of code. We use this in Foundation to produce grid classes, typography styles, visibility helpers, and more.
There's some subtlety to how a loop produces code, however. We came across this while developing Foundation 6.
Here's a basic loop to produce a series of grid classes. It loops through each breakpoint, and then loops through the numbers 1 to 12, to make the .small-12 and .medium-6 classes you're used to.
Here's the CSS output:
If you look at the CSS this produces, it does what it's supposed to, but something's not quite right. This loop creates a media query for every class! That's a lot of redundancy. All 12 of those .small-* classes could be under one media query. Same for medium and large.
Here's the CSS output:
By putting the media query outside of the inner loop, it only prints once. This saves us about 20 lines of code. That may not seem like much, but you may have read in our last post that the Foundation 6 CSS will be almost half the size of Foundation 5's. Every little bit helps!
Example #3: Component Mixins
Component mixins are a signature element of the Foundation Sass. We don't just create mixins for the grid— we create them for every component, allowing you to recreate our CSS with your own class structure if you want.
While this feature makes the framework very flexible, it comes at the cost of greatly increased complexity, not only for people using the framework, but also people contributing. For Foundation 6, we've scaled back the complexity of component mixins quite a bit. There will be less of them, and the ones remaining will have fewer parameters. All this will reduce the amount of overhead in using the framework.
Mixins are an abstraction, so they need to be a useful abstraction. If it's just recreating something that's easy to do in CSS, it's not a useful abstraction. Let's look at an example from Foundation 5. It's a mixin to style a Reveal modal.
It's pretty easy to see what all of these parameters do. The first one changes the background color of the modal. The next four change the border, and the last two change the box shadow and top offset respectively.
Each parameter prints one CSS property, which begs the question— what's the utility of this mixin? It's not automating anything for us, or doing anything magical. It's just printing CSS. It would be faster to just write the CSS yourself.
Now this doesn't mean we've gotten rid of component mixins. Every component still has them! But they're all way simpler, and designed to be as efficient and useful as possible.
The Player, Not the Game
Sass is an amazing tool, but like any tool, you need to know the right time to use it. After two years working with Foundation 5, we found we were using Sass a little too much. But we can't imagine life without it, and when Foundation 6 ships later this year, you'll be able to leverage our slimmed down, simpler codebase to learn and build faster than ever.