I have to admit: when I first heard about BEM, I thought it was a bad idea. Why make your CSS naming so complicated? Surely you can get by with simple class names like
.accordion. Why do you have to get all crazy with classes like
In a project in January, I worked with Jelle who was using BEM-style syntax in his code. At first I was hesitant but since he was the lead HTML/CSS guy on the project I let him do his thing.
After learning more about BEM I am convinced: the method really has its merits. It is mostly useful in the context of a large scale web application with a lot of components.
Think about an admin interface with a lot of widgets and screens with different states. Think about software that has to be stable, with many people working on different CSS components. Here, BEM makes a lot of sense.
The logic for BEM (Block – Element – Modifier) is:
.my-element__sub-element(the 2 underscores denote sub elements)
.my-element__sub-elelement—highlighted(the 2 hyphens denote a modifier state).
A longer explanation is here.
This has some advantages:
Of course, BEM has some disadvantages as well:
For me, for small sites maintained by a few people or a single person, it’s unnecessary to use BEM, and I would rather use normalize.css and a set of easy to type class names.
For large software projects (the type of application CSS we usually write), BEM is the way to go. It costs a bit of effort in the beginning but saves a lot of time in the long run. Onwards!