Working on an extensive development project with a lot of pages, a lot of CSS selectors, and different developers involved, makes the maintenance of the CSS styles difficult.
Problems regarding CSS specificity often arise, and the altering of components in one area may affect components in another area, and so on.
In order to deal with such issues, and in order to organize the development process, a lot of dev teams invented name conventions for CSS classes, with BEM being one of the most popular among them.
BEM is an agreed set of rules for naming classes that were invented by developers at Yandex in order to keep their CSS maintainable and easily supported.
Since then, it has become one of the most popular name convention methodologies.
A BEM class name comprises 3 parts: the Block, the Element, and the Modifier.
All three are combined as follows:
[block]__[element]--[modifier]
The rules of BEM
- Names are written in lowercase
- Words within the names of BEM entities are separated by a hyphen “–“
- An element name is separated from a block name by a double underscore “__“
- Boolean modifiers are delimited by double hyphens “—“
Example:
…example
Let’s dig into each one of the three parts to make the distinction more clear:
The Block
The Block represents an independent, reusable UI component on a webpage, for example, a button.
That component can be reused in other parts of the webpage. We can even place blocks one inside the other (nesting).
…example
Here both card and card-container are blocks. The card block is nested inside the card-container block.
The Block in each component plays the role of the top-level abstraction. Inside it, we can include child components that are part of the parent component.
The Element
The Element, is the name we give to the child components. These components are depended to the Block, and they cannot be used separately from it.
Consider the following code:
…example
Here, the _card_ component consists of the children components of card__image, card__title, card__description and card__button. These entities are created to be used inside the card.
Same as with the Block entities, Elements can be nested inside each other.
…example
An Element cannot be part of another Element. The following code violates the BEM rules.
…example
The right class name should be:
…example
Elements are optional components of a Block.
…example
The above code is not incorrect, but it certainly is less maintainable.
So when maintenance is an issue, like in a big or medium size project, we should keep that in mind. On the other hand, if the project is super simple, like a landing page, for example, then omitting BEM is just fine.
I make a note to use BEM anyway, irrespective of the size of the project, in order to get used to BEM methodology.
When to create an Element instead of a Block?
We create an Element when a part of the component cannot be used separately without the parent element. This decision is for the developer to make according to his preference and the specific needs of the project.
For example, .card__content, in the above example, is an element because in this case we don’t want general content to have the same styles as the content inside the card. So we couldn’t possibly use this piece of code outside of the card component.
The Modifier
The Modifier, represents the style differences of the Block component.
With the Modifier we change a specific instance of a block, regarding color, state or behavior.
Removing or adding a Modifier should only affect the specific component and not the surrounding ones.
Example:
…example
Here, we changed the color of the Element card__button with a Modifier. The other elements in the card stay intact.
Other than appearance, a Modifier can affect the behavior:
…example
In the above example, the card__image–slide Modifier can, for example, make the image slide for 30px to the right when on hover or something similar.
They can also affect the state, for example:
…example
Here the button can get special styles, for example green borders, when is active.
We can also add more than one Modifiers to a Block.
…example
Why using BEM?
For a medium to extensive project, with an ever-growing codebase, and a lot of developers involved, a class name methodology like BEM can save developers from a lot of headaches.
The reasons to use BEM in a nutshell are:
It is modular: With BEM we write small, independent and reusable components that have a descriptive name, and are easy to find in the code, and easy to modify without mistakenly affecting other components or pages.
It is readable: The names are self-explanatory and descriptive. This makes it easy for web developers to understand the purpose of each class.
It is clear: The hierarchy of class names is very clear. We can more easily avoid specificity issues.
It is great for collaboration: It provides a common structure for a team of developers working on the same project.
Although my blog doesn’t support comments, feel free to reply via email or X.