BEM Blocks and Elements

At the time of this writing I have been actively using BEM for almost a year. Well, not all of the BEM tools, I don’t need most of those. The way I prefer to use it is similar to the one used by many front-enders like Harry Roberts or Nicolas Gallagher. One of the most common misconceptions about BEM is that its Block is quite a big (typically structural) entity on a page, like header, sidebar or footer. I’ve seen it in different places and lately it has been described in the article on BEM on TutsPlus. Although I disagreed with such a definition in the comment I received a pretty good reply from the post’s author.

I agree with you Alex, the most important rule of CSS selectors is to keep things DRY (don’t repeat yourself). That’s important in any codebase. At the end of the day, it’s up to an individual or a team how they want to define blocks, elements, and modifiers :)

Josh Medeski

Can’t but agree. If it works for you and for your team that’s great. But such a broad definition of a block does not allow it to be greatly reusable which we would actually want.

What is a Block?

If we look into the abbreviation we will see that according to its authors there are only two types of entities on a web page. They may be either Blocks or Elements. And that’s it. If an entity is independent on its own – that a perfect block. If an entity cannot exist without and forms its parent – that’s an element. As simple as that.

The way I see it a Block may be as simple as a site logo.

In contrast to the TutsPlus’ variant we shouldn’t use it in the form of .header__logo which is an element logo that belongs to the block header. Such a version makes it hard for us to reuse this component somewhere else. Well of course we can reuse it in our sidebar or footer but, y’know, .header__smth in the footer is not comme il faut.

Instead, .site-logo or just .logo will suffice. It is perfectly reusable throughout the page(-s) be it in the footer or sidebar and if we need to modify it in its new place we could add a Modifier to it. Thus we will have .logo--sidebar for instance, or .logo--halloween if we need.

I also tend to extend the BEM terms even further. In my projects I use the classes like .grid and .grid__column which are Block and Element respectively. But you cannot even see such Blocks on a page… or such Elements either. They are structural entities that hold other blocks.

It may of course not fall into the Yandex’s understanding of Blocks and Elements, but using such naming principles truly increases the understanding of the code and the relations between entities.

  • Serge Zarouski

    Would it make sense to use .header__logo for following markup in case when you need to extend .logo styles to fit it with other blocks within .header? Or would you create a modifier for .logo?

    • http://alexbondarev.com/ Alex Bondarev

      That’s a good question. Back in July I participated in a conversation on .header__nav vs. .header .nav, where I stated that I would never use .header__nav because navigation is a perfect block, not an element. So I said I’d use .nav--header instead. I partially agree with my past self, but I shouldn’t have said never that easily )). My answer now would be like this – “Well, it’s complicated, maybe in some cases .header__logo would make sense, but definitely it should not contain all of the styles”. I feel I need to write another post on BEM, where I will try to explain what I’d use and when. Thanks for the nudge :)

    • http://alexbondarev.com/ Alex Bondarev

      @szarouski:disqus, if you are still interested in my thoughts on the topic, please take a look at the post on BEM modifiers I’ve just written.