Login with github

Hi, some time ago jQuery team asked us about BEM, and we cleared a lot of points for them. Answers are quite useful, so we decided to publish them free.

1. How easily is BEM kept maintainable long term?

Easy maintenance is what BEM was invented for.

Actually all the issues with CSS maintenance are because of cascade and strong coupling of components. And BEM is all about independence of blocks and reducing cascade to minimum level.

We have a lot of real experience with BEM on our portal and it proved to be a great solution.

Example 1.

ul a {
    position: absolute;

won't work as soon as you'll get second level of nesting for lists.

Example 2.

Considering menu can't have any other list items:

ul.menu li {

and then some components with own dropdown with own menu appear in list item.

2. The long class names can come off a bit intimidating and unfriendly for beginners using BEM. What is the justification behind the longer names? As it is now, we already have many people complaining when we use ui-button for a class name instead of btn, because the former is too long.

Well, BEM does not restrict usage of btn instead of button ;) You can consider any naming strategy you want. E.g.: context or ctx or c, attributes or attrs or as.

The choose is yours — BEM doesn't srink you.

There is still some "problem" with elements and modifiers, i.e. btn__txt and btn_hvrd, but we strongly believe that there's no real problem in typing. And of course there's no problem with kilobytes due to gzip. But what is really important for huge rapid projects which live for a long time is code readability and self-descriptive names of components is just a must.

Not so cool for common block library with a huge amount of users.

3. The namespacing decisions in general - members of our community would like a greater explanation of this.

That was something odd when we invented BEM. But right now that's a common idea: OOCSS, Atomic CSS, etc. and web components standard try to hide internal world of a block from other ones. Web components use shadow DOM, BEM uses namespacing to achieve the same result but without necessity to wait for support from browsers or any additional JS.

Historical reason of having namespaces for modifiers is that joined selectors like .a.b were not supported in old browsers. Not it's not a restriction but in BEM there's also a concept of mixes — possibility to have a few different entities on the same DOM node. And namespaces help to distinguish modifier of which block is it.

Without mixes it's possible to have .btn._hvrd but we are sure that mixes are useful thing.

But what is often left in shadow is possibility to mix different entities on the same DOM node. E.g. it's possible to have <input class="input form__login"> which means we've got an input block (can be reused somewhere else) and login element of form block at the same time. So everything about abstract input will be provided by .input selector and things like margins, etc — with .form__login.

4. Neutering the Cascading potential of CSS code by making everything overly specific.

Yes, that looks strange at the first sight but soon you'll find it very convenient. Cascade is cool for fast write-and-throw-away approach. But when we need bullet proof reusable components it just doesn't work.

Cascade creates strong coupling and results in impossibility to reuse such code.

5. The arbitrary distinction between blocks and elements.

Let's look at JS (actually OOP) analogy. JS class point [x, y] is just a field of Figure class or one more class Point. If it has a lot of methods it's most likely a class by its own. Otherwise field is enough. The same is for blocks and elements. It's always for your consideration.

With practice that's easier than it looks. When an entity is impossible without its parent — that's an element. When you find yourself trying to reuse an element somewhere in a project without its parent and inner complexity of element became bigger — that's a standalone block.

But what is often left in shadow is possibility to mix different entities on the same DOM node. E.g. it's possible to have <input class="input form__login"> which means we've got an input block (can be reused somewhere else) and login element of form block at the same time. So everything about abstract input will be provided by .input selector and things like margins, etc — with .form__login.

In the simplest form a block is represented by a single DOM node but generally blocks and DOM nodes are not the same thing.

Mixes are just the way to use several blocks and/or elements on the same DOM node.

That makes possible

  • combining behaviour and/or styling of different BEM entities without copy/paste
  • building new semantic components based on existed blocks.

For instance, we have a universal block logo (a block with a logotype) that could be used anywhere on a page: in header, inside copy, in the footer, etc. We can specify its width, height and a background image but what we do with its margins that differ from case to case?

Of course, we could use modifiers like logo_type_header or logo_type_content to do so. However it is wrong semantically, because such things should lay down within a scope of parent block’s responsibility. And giving the right to define such things to an inner block contradicts the whole idea of blocks independency.

That's where mixes shine:

<div class="header">
    <div class="header__logo logo"></div>
    width: 120px;
    height: 60px;
    background-image: url(logo.svg);

    margin: 12px 26px;

As you know there's no global modifiers in BEM methodology but again — mixes gives us possibility to achieve the same result with several different blocks on same DOM node.

Also you may want to use mixes to provide some arbitrary block with JS logic.

A single DOM node can represent:

  • several blocks <div class="menu head-menu"></div>
  • a block and an element of the same block <div class="menu menu__layout"></div>
  • a block and an element of another block <div class="link menu__link"></div>
  • elements of different blocks <div class="menu__item head-menu__item"></div>
  • a block with a modifier and another block <div class="menu menu_layout_horiz head-menu">
  • several different blocks with modifiers <div class="menu menu_layout_horiz head-toolbar head-toolbar_theme_black"><div>

So try to develop your blocks as small and reusable as possible and then combine them in any way you want to build huge applications!


Today there has been a BEM workshop in our company (SC5 Online, Helsinki, http://sc5.io/) We studied basics like CSS approach and modular file structure. People did their tasks one by one "at the stage" :-) These are the slides, and the task is inside http://varya.me/bem-css-workshop/

Finishing the tasks we could compare the changes we provided without BEM in mind https://github.com/varya/bem-css-workshop-source/pull/1/files and with BEM https://github.com/varya/bem-css-workshop-source/pull/2/files In my mind, it shows the different very clearly and it is easier to understand the idea of BEM. Even better than presentations and the articles.

BTW, I was surprised to learn that many don't know about BEM selectors supporting in SASS and LESS although this is at least 1-year-old feature.

How is it in your mind? Feel free to use slides.

Recently we learnt that cascade term was used wrongly all the time. Spec: http://www.w3.org/TR/2009/CR-CSS2-20090908/cascade.html#cascade What are you going to do with wrong usage of this term in this website? For example Max uses it here https://en.bem.info/articles/bem-for-small-projects/#bye-bye-cascade-4 And so do I in this article https://en.bem.info/articles/yandex-frontend-dev/ And I guess in many places all over the website.

Hi everyone,

We are ready to launch our BEM forum — a place where developers working with BEM can get together, share their experiences and ask questions directly to the BEM team.

Little bit of history

We wanted to have our own communication platform for a long time.

Before we launched BEM forum on bem.info for Russian language community in August 2014 we had to monitor a lot of social media platforms such as twitter, Yandex blog platform, facebook, in order not to miss your questions.

At the same time Yandex was shutting down it's blog platform, and that decision forced us to launch the forum.

We carefully planned it, have chosen github to host everything as well as to login through and we went live as well as moved in to github 5 years of blogging history that we wanted to keep.

We were worried from the beginning that useful channels of communication will still prevail, and developers continue to ask questions everywhere and not here that is time consuming in terms of search and not usefull at all for archiving the history for the sake of future users.

But forum proved us wrong: the number of posts grew up every month, and it is about 40 posts (issues) per month now.

Inside the forum

As we do almost everything in open source, forum is an open sourced platform too. This means we encourage you to use it in your home projects and report bugs.

The repository could be found here. Local copy installation instruction is in it's readme file.

Forum's architecture allows using it well as a separate service and as a route for express. We use it in a second capacity — it is a part of bem.info site.

We use github API as a source of data, node.js for backend and full stack of BEM (BEMTREE, BEMHTML, i-bem.js) for frontend.

Right now it is possible on BEM forum to open a topic, comment it and filter posts using labels. We already made few necessary for you there. And if you lack one or have a question regarding the work of the forum, just open a topic and mark it with "bem-forum" label.

Every post is an issue on github that we browse on the site. This scheme allows communicating via forum having what developers already have — github login.

Attention: we ask you to use our forum via bem.info interface, because here you can have it labeled and found by others.

All you need to start using BEM forum is to authorize via oAuth using your github login.

Start writing your first post right now! We as a BEM team and guys from the community monitor user questions all the time and answer them right away.

We also hope you open our eyes on the problems English language developers have with BEM (anything from documentation to demos, from installation to use cases). Just mark such posts with "bug" label. It will be a lot of a help!

Let's get started with BEM forum!