BEM it! Introduction to BEM methodology
A tidy code is a sacrosanct and everybody knows that. But how to get down to it? Fortunately, somebody has already asked that question before. The implementation of CSS naming convention for classes is the answer.
There are several leading CSS naming conventions. The most popular are certainly OOCSS, SMACSS, SUITCSS, Atomic and BEM. Although it is worth to learn the basic of every one of them, I’ll focus on the last one.
Why would we bother with CSS namnig conventions for classes?
Imagine that we have a big project and a number of programmers are working on it. Deadline is set, and it’s at least a few months. Sounds like a perfect recipe for big chaos, isn’t it? When these kinds of situations occur, an appropriate organization of HTML and CSS code can work miracles.
The proper selection of methodology of classes structure allows us to write code faster and also reduce it. Some of the conventions (for example BEM) improve not only the quality of CSS code but also the HTML code. Following the rules enhances cooperation between devs and significantly reduces the time required to introduce new people to the project.
OK, but it works only with big projects, right?
In my opinion, it is always worth to write code following some methodology. Let he who has never taken part in „small project” that grew in time to unimaginable big, only because the client wanted to add „just another functionality” cast the first stone. I think you get it :)
BEM — what is all about?
BEM (Block, Element, Modifier) is one of the most popular CSS naming conventions for classes. It’s based on three essential components: blocks, elements, and modifiers.
The first rule to remember is about naming of classes:
- the names should be written using numbers and lower case Latin characters (do not use camelCase)
- individual words within names should be separated by a hyphen ( — )
- use only classes to write blocks, elements and modifiers
Let’s find out something about individual components characterization and learn when we should use them!
Block is a top-level abstraction of a new component. We can compare it to a container in which we put part of the code. The block should be a fully independent piece of the site. The main feature of the block is a possibility of re-using them anywhere on a page. Also, blocks can be nested inside any other blocks.
A block name should clearly define what particular part of the code is responsible for. For example, let me take a class .btn that is used to pin down the buttons.
The element is a constituent part of a block that is assigned to it and can’t be used outside of the block.
A name of the element consists block name and element name. The element name has to be separated by a double underscore ( __ ). Based on previous example, we can create the elements like .btn__category and .btn__name.
A modifier is a flag that can be assigned to the block or element. It’s used to change appearance or behavior of the element. Modifiers are also used to set particular states apart.
Modifier name is defined by block’s or element’s name that we want to modify and two dashes ( — ). To go a little further with our example, let’s say that we want to set apart two button’s states which can vary from one to another in background color or other properties. To this end, we want to add to block .btn the classes .btn — positive and .btn — negative.
BEM hand in hand with Sass
Looking at the above example. Certainly, you have noticed that I used an ampersand ( & ) in the Sass code. This mark allows you to refer to the parent element, in which the selector is nested. In the final code, it will be replaced with the parent class. As a result, I make the code shorter and more readable.
You can find ready-made Sass mixins on the Internet. It seems to be extremely broad subject and, to be frank, I have never had to go into it. The default parent inheritance mechanism is enough for me. I think that using them make sense only in case of more complex class nesting which I avoid in my projects. After all, we try to code on the line with KISS principle (Keep It Simple, Stupid).
I recommend trying to work with just a few conventions at the beginning. Then you can decide which of them is the best for you. In my opinion, there are no good and bad conventions, but there are only those that suit you better. I chose BEM because it gives much room for maneuver using with Sass.
Just remember one thing, it takes some time to get used to new way of naming classes. But believe me, it will be worth it. The benefits of using BEM (or other methodology) are imponderable on time spent on learning and getting used to.
Finally, the last and the most important thing — the consistency. If you decide on some methodology, use it from the beginning to the end in one project. Unless you want to burn in hell frontend hell ;)
Originally published at www.merixstudio.com.