BEM and SASS: A Perfect Match

Fish and chips, Posh and Becks, Netflix and chill. These are all things that go well together; or so I’m told. It’s time to add BEM and SASS to the list.

What are they?

• BEM (Block. Element. Modifier) is a naming methodology, which aims to solve many of the problems you’ll commonly encounter when naming classes and structuring your CSS. It also does a great job of enabling you to create reusable front end components, which is something we all strive for: to be healthy, wealthy and create reusable components.
• SASS on the other hand, stands for Syntactically Awesome Style Sheets. Way to blow your own trumpet. Although, “awesome” is potentially an understated adjective for this thing. Their tagline, “CSS with superpowers” pretty much covers it. It allows you to nest selectors, create loops, functions and all the fun stuff that you wish you could do with CSS.

If BEM is the cake, then SASS is the icing.

Traditional example

Taking the above navigation bar. Traditionally in 1999 (if HTML5 elements were a thing then), we may have created the following markup whilst listening to Nickelback on Napster. Everything works great, we get the navigation bar we want.

However, there are a few problems with the above approach:

• To target those li you’ll need to be doing something like .nav li. What happens if we want to change the list to instead be a group of divs? The CSS needs updating as well as the HTML.
• .active may well be declared somewhere else in the CSS. Which may start conflicting with the styles. Especially if the conflicting selector comes in after you’ve created the navigation bar; you may not even spot the conflict until it’s too late.
• This can’t be modular. It can’t be dropped anywhere in your code. What’s to say with this approach we don’t have .header li with some conflicting styles. It’s a never ending battle with specificity — easy for you to say.

BEM example

Taking the above example, and applying BEM to it, we’ll end up with something like this:

What we’ve done here is call out the .nav as the Block. Anything with double underscores __ are our Elements within that Block. And anything with double dash -- are our Modifiers.

So we’ve added some bloat and it looks a bit messy. What are the upsides?

• The class selectors in this component will (hopefully!) be unique. So other than stuff like fonts and colours that will always cascade, you don’t need to worry about conflicts.
• We can change the HTML elements without having to change the CSS.
• We’re being explicit. If we have nested elements that are the same in the component, it’s not a problem. They have a unique class that we can target without impacting the outside world.
• You get into good habits about naming classes and it becomes second nature and consistent.
• Best of all, we can pretty much just drop this component anywhere we like. Reusable components. Life goals.
• I could go on, but I’m super lazy.

BEM and SASS example

Ridiculous analogy incoming: If BEM is the cake, then SASS is the icing. One of the small but incredibly powerful features you get in SASS, is the ability to nest your class selectors.

So because we know the block is called .nav, to save us writing out .nav__list, .nav__link--active etc, we can do the following:

The & essentially saves us rewriting the parent selector over and over. What we end up with is the styles for our nav component encapsulated into a single block. Having the classes in one block like this makes it easy to identify, edit and move around.

Conclusion

With this approach, you can start to create modular and reusable front end code. It also allows you to start being a more confident and less anxious coder. Largely because you aren’t forever worrying about what specificity issue you might be running into or indeed creating.

Reusable front end code. Life goals, right? I now just need to work on the health and wealth part.