Unclutter your CSS with Block-Element-Modifier (BEM)

Have you ever worked in an HTML Project and had to set the font color of a title? You gave the surrounding div a CSS class with the name title and declared the color attribute in the “.title” section in the CSS file. You committed your change in Git and you were happy that you had finished your task. Only to find out about 5 minutes later that you had also unintentionally changed the title color on some other pages in your project. So as a solution you tried to find a very broad CSS class that is somewhere up the DOM that would not interfere with other pages or you created one of your own and referenced in the CSS with a cascading “.mypage .somesection .title”.

© Simon Sharp

And when you were done there you figured out that you completely lost oversight of what is where and you were not sure if you are going to break something again once you entered another class. Let alone got lost in chaos once I had to refactor my code. I surely have. And more than once I have cursed about the structure and stupidity of CSS.

Then one day I was applying for a job. And in the job description I found the need for knowledge of BEM or SMACSS. I took a quick look at what it is and found the solution to my CSS frustration.

In short: The solution is to write your CSS class name in a structured and meaningful way.

Description

Let’s have a look at BEM. Its going to be the one approach I will focus on in this text. BEM stands for Block/Element/Modifier and can be looked up on http://www.getbem.com. There is nothing to download to work with this approach. It’s completely conceptional.

The goal is to provide such a meaningful name for a class, that it is always going to be unique in your project. As a result, it will hardly ever be necessary to cascade the class names in your CSS file. You are always working on the first level. So let’s have a look on who BEM asks you to set up the class name.

block__element — modifier or when used in an example offer__title — overdue

First, we start with the Block part. The Block refers to the page or component you are writing the CSS for. In my example I go with the offer page. The offer page might have several sections like title, description, pricing information and so on.

So those sections are named Elements in BEM. Make sure that you give them meaningful names and if possible do not repeat yourself. Of course, it is possible to have CSS classes with the same name on a page. Specially if you loop over something. That’s why we are talking about CSS classes and not id’ s. But make sure that when you are using the same name that the element has the same structure.

Blocks and Elements are already enough to give the class name for what we need in most cases and it’s completely ok to just use those two parts.

The Modifier comes into play when the element you are referring to has several states. Like active, inactive, state-success, state-danger, overdue or whatever you need in your project.

Possible downsides

Too much information: Now when someone uses BEM on their page for the first time, they might say that they struggle with creating a lot of redundant information. This is because the page name is now visible n times in the html. There is nothing that I can say against that. I can only refer to the benefits we get when we are not destroying our colleague’s CSS.

SCSS

When we are using SCSS we do not have to repeat ourselves in the CSS file. With SCSS it is possible to concatenate string by using the & character.

.offer {
     &__title {
          &--overdue {
                color: red;
          }
     }
}

So, we don’t have to repeat ourselves and also changing the names when renaming something is much faster.

In an Angular Project

When we are working in an Angular project the CSS is already separated by Angular. If we are writing CSS for one component it is separated from the CSS in another component. So does it makes sense to use BEM in an Angular project? In my opinion it does. It’s also not the case that it puts too much information into the HTML part.

In Angular it is also possible to declare styles in the styles.scss file that applies to the entire project. With this it would be easily possible to generate a theming for our project.

So I would highly recommend to also use BEM in your Angular projects.

Benefit for support and bug fixing

The last point I want to mention is the benefit when your project comes into the maintaining phase of the project. Or if you have found a bug in your program and need to find the location in the thousand files you have in your project. BEM class names are supposed to be unique. Therefore, you will land on the correct spot to solve your bugs every time.

The Future of BEM

There are several technologies that already exist. Like “CSS Modules” and “Styled Components”. Just to name a few. They move the CSS into variables so they can also be used over a JavaScript import section. The creation of the CSS is then done during the webpack build steps or during runtime.

Like any tech this comes with some advantages and disadvantages. Currently I am personally happy with using BEM and I might point out some reasons why this is the case. I might be wrong.

• Both of these concepts break down easily when not only applied to classes.
• You need some additional setup to get it working that currently not come out of the box.
• It does not support you in any ways when you are debugging or testing your code because it hides the spot where the declaration is made in the HTML output.
• They both work well if you have general styles, but thats a place that is covered well by the scss mixin/import declaration.
• And finally, it is sort of what Angular is doing with the encapsulation of the components.

So, I accept that there is newer technology to work with CSS. But I would say that this then can be handled in another Blogpost.