What is BEM?

BEM is a naming convention that aims to create a consistent structure for creating CSS class names. The goal of BEM is to help the developer better understand exactly what they are targeting in their CSS. Too often  new developers (myself included) ask themselves “what the hell do I name this div? I already called the other dive a container!”. BEM aims to clear up confusion and that feeling of helpless class naming by providing a clear structure.

Block. Element. Modifier.

First we examine a ‘block’. A block is a top level extraction of an element. This element has children within it. A BEM ‘block’ is often a block element; buttons, navs, and sections.

Next is an ‘element’. These are characterized as html elements which are tied to a parent. BEM elements have no meaning outside the block that they are in. These can range from containers, to list items, or even table cells. Elements often require their parents (blocks) in clarification of where they are in the HTML structure.

Last we have ‘modifiers’. Modifiers flag elements or blocks for different states. They often define unique properties about a block or elements that are used once or twice. These might be colours, sizes, or booleans(true/false).

Okay. What does BEM even look like?


BEM follows a very specific structure.


This convention ensures absolutely clarity in creating very specific class names. As seen above we have the header. Within the header, there are two elements, the logoContainer (which I have chosen to write in camelCase, but any naming convention works within BEM), and the nav.

Nav and logoContainer their own children. These two elements now become the BEM blocks. In the nav we have list items, and in the logoContainer we have a logo. In the nav we can see an example of a BEM modifier showing us a separate ‘state’. One of the list items, the page we are currently on, is tagged with ‘–selected’. Thanks to we BEM know that this one item will look different than it’s siblings because of this modifier tag.

Why is this even helpful again?

When you are simply writing BEM HTML the class names seem redundant. Why not just target the list items in the nav by writing something like this;


The above looks like it will create the desired result, but once documents get more and more complicated, the above CSS will begin to target more than expected. Imagine a scenario where you have multiple navs elements on one page, with many lists inside of them. Do you truly want all those items to have red text?

Moreover the above CSS will lead to specificity issues. When you begin to try and change things via adding more classes, these declarations will still reign supreme. You will run into confusing messes of scattered red texts in lists throughout your page because specificity will be scattered and harder and harder to determine. This can lead to a lot of frustrating situations for new developers.

Oh gosh, that sounds terrible.

Enter BEM CSS.


The above is an example of creating CSS selectors that all have the same specificity. Because we are only target classes to apply styles all that matters is the cascade of CSS. Moreover, BEM ensures that upon returning to your code you will be able to know what all your declarations are targeting.

So what’s bad about BEM?

In my limited experience, adding more structure and guidelines to my front-end naming style has had no draw backs. BEM Class names can end up being very long but they are very specific. As long as you stay vigilant with BEM naming convention, you will be sure of what you are targeting.

BEM is a fantastic tool for devs beginning their journey because it really enforces the hierarchy of HTML. In every class you create you have to ask yourself “which is the block, and which is the child?”. The addition of modifiers enforces the idea of modular reusable css, introducing the idea of states, themes and various more advance html/css concept that will help you create more dry and maintainable code.