by Yen H and Laura S
Surely you’ve asked yourself this question more than once when you’re styling your HTML code.
What do I call this class?… Have I already named another one with this name?…. Do I separate the class names with camelCase, with a hyphen, a middle script …? Or worse yet … do you end up giving them names like “.paco”, “.ramiro” …? … ’
These are all questions that go through your mind while you structure and give styles to your project.
Learning a form of naming classes is not easy, but once it is achieved it is very useful. They will help us to write css code in a more flexible, reusable, understandable and manageable way.
So let’s learn a little bit about class naming system.
The Block, Element, Modifier methodology, (commonly referred to as BEM) is a popular naming convention for classes in HTML and CSS.
Developed by the team at Yandex, its goal is to help developers better understand the relationship between the HTML and CSS in a given project.
It is based on making differences in CSS classes that fulfill different functions by naming the CSS classes in a special way, so that their names describe their function.
In BEM terminology, a block is an independent, modular user interface component. A block can be composed of several HTML elements, or even several blocks. An example of a block could be a navigation menu or a search form.
An element is a component of a block. An element serves a singular purpose. For example, if we have a navigation menu block, its elements could be the elements of the list (elements li) and the links (elements a).
A modifier is a css class that changes the presentation of a block or element.
So, summarizing, we have:
- Blocks : Independent entity that has meaning by itself (header, container, menu, checkbox, input …).
- Elements : Parts of a block that have no independent meaning. They are semantically linked to your block (element of a menu, element of a list, title of a header, caption of a picture element, etc …).
- Modifiers: Block or element indicators. Used to change the appearance or behavior (disabled, highlighted, checked, fixed, size big, color yellow …).
Let’s see an image that illustrates perfectly these:
We can see the blocks in green, the elements in blue and the modifiers in red.
This is the BEM syntax system:
- .block
- .block — modifier
- .block__element
- .block__element — modifier
For all those who have come here and still do not understand, it is as easy as:
.button .button__state — success
.body .body__ head — hair.
Where : .body is the .block.
head is an element of the body so .body__head is like .block__element.
and hair is an modifier of the head and, of course, of the body.
Now, you see it better, right?
Let’s do an exercise to put in practice what you have just read.
Practice:
We have a normal button and two possible states for it.
HTML would be:
And the CSS applying the BEM principles and nomenclature:
Why should we consider using BEM?
If we want to make a new style of a component, we can easily see which modifiers and children already exist. We might even realize we don’t need to write any CSS in the first place because there is a pre-existing modifier that does what we need.
If we are reading the markup instead of CSS, we should be able to quickly get an idea of which element depends on another (in the previous example we can see that .btn__price depends on .btn, even if we don’t know what that does just yet).
Designers and developers can consistently name components for easier communication between team members. In other words, BEM gives everyone on a project a declarative syntax that they can share so that they’re on the same page.
Harry Roberts identified another key benefit of using a syntax like BEM when he writes about improving developer confidence:
“This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we dare not touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS’ globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don’t know what things do any more. People dare not make changes because they don’t know how far reaching the effects will be.”
Likewise, Philip Walton argues that this problem can be fixed if enough developers stick to the principles of BEM:
“While 100% predictable code may never be possible, it’s important to understand the trade-offs you make with the conventions you choose. If you follow strict BEM conventions, you will be able to update and add to your CSS in the future with the full confidence that your changes will not have side effects.”
Another smart part of BEM is that everything is a class and nothing is nested. That makes CSS specificity very flat and low, which is a good idea. It means you won’t end up fighting with yourself over specificity.
Never make the mistake of naming classes of this type:
Summarizing this, we come to some of the benefits of using BEM:
Modularity: The styles of the blocks should not have dependencies with other elements of the page. In this way, we will avoid cascade change problems.
In addition, these modules / blocks can be reused for other projects.
Reuse: Composing independent blocks and reusing them reduces the amount of CSS code to maintain.
Structure: BEM grants a simple and understandable structure to your CSS code.
CONCLUSION
BEM is extraordinarily useful for building scalable and maintainable interfaces. It makes the front-end code easier to read and understand, and makes it easier for other people to collaborate on a design.
