Login with github


I have a big disscusson with my colleague and would love to get your feedback.

I am building a website and have seen some areas, wich are reusable. They share the same HTML construct and looks similar. Example:

    <nav class="navigation navigation_main">
        <ul class="navigation__list">
            <li class="navigation__item"><a class="navigation__link">Item 1</a></li>
            <li class="navigation__item"><a class="navigation__link">Item 2</a></li>
            <li class="navigation__item"><a class="navigation__link">Item 3</a></li>
        <nav class="navigation navigation_meta">
            <ul class="navigation__list">
                <li class="navigation__item"><a class="navigation__link"><span class="svg-icon svg-icon_search"></span></a></li>
                <li class="navigation__item navigation__item_active"><a class="navigation__link">DE</a></li>
                <li class="navigation__item"><a class="navigation__link">EN</a></li>

My colleague says, that the navigations have to be named different:

    <nav class="main-navigation">
        <ul class="main-navigation__list">
            <li class="main-navigation__item"><a class="main-navigation__link">Item 1</a></li>
            <li class="main-navigation__item"><a class="main-navigation__link">Item 2</a></li>
            <li class="main-navigation__item"><a class="main-navigation__link">Item 3</a></li>
    <nav class="meta-navigation">
        <ul class="meta-navigation__list">
            <li class="meta-navigation__item"><a class="meta-navigation__link"><span class="svg-icon svg-icon_search"></span></a></li>
            <li class="meta-navigation__item meta-navigation__item_active"><a class="meta-navigation__link">DE</a></li>
            <li class="meta-navigation__item"><a class="meta-navigation__link">EN</a></li>

The navigations (there are some additional navigation in the footer and for social media icons, too) looks very similar. They differ in font size and paddings/margins. I see great advance in the first solution, because it is very modular and reusable. The end code is smaller. My colleague says, nesting (i.e. .navigation_meta .navigation__item{}) is evil and should be avoided, whenever possible (i.e .meta-navigation__item{}).

Who is right?


I've adopted the directory organization where each block and element have their own directories. The problem with this apprach is that when I have a style like this:

.tile__textual-part {
    display: table-cell;
    vertical-align: middle;

I do not have a choice but to repeat the same style definition in both tile__icon-wrapper.sass and tile__textual-part.sass.

Is there a sensible way to get rid of this redundant repetition and still adhere to BEM's principles?

Hey all!

I made a couple of silly, simple little snippets to detect improper usage of Elements and Modifiers.

Very simple, not necessarily failsafe or bulletproof, but a quick ’n’ dirty start. I need to DRY them out and roll them into one at some point as well.

The thinner the footprint the better.
Without all the heavy lifters like enb, only bem-tools maybe.

This is what I try:

npm install -g bem
mkdir bem-playground
cd bem-playground
bem create level my-blocks
bem create -b foo-block -l my-blocks -t <WHAT TYPE TO START WITH?>

html type is deprecated, list of types, I guess, is here: https://github.com/bem/bem-tools/tree/master/lib/techs/v2
Default types are empty so no block is created without -t.

Ok, I can create block manually. But what's next?
To assemble blocks into a page, I guess, I need some bemdecl and some assembler (enb again).
So I can't escape complexity footprint of enb onto my stack, right?

Can I mix Polymer and BEM (techs, tools, everything behind the methodology)? Does it worth it?

Ok, I've made a feature comparison table.
I need it to figure out if one technology can supplement another, not to downplay one of them.

Feature BEM Polymer
Syntax conventions (for B, E, M) yes no, use BEM
Decomposition into components ENB assembler (*) HTML Imports / webcomponents.js
# of requests reduction ENB assembler (*) vulcanize
CSS encapsulation upper boundary (*) upper boundary, lower for Native Shadow DOM (unstable)
Component redefinition yes, orginized in levels, ENB? (*) limited: extend native tags, inherit javascript definitions (behaviors), more is planned
File structure organization yes, B,E,M, techs no, use BEM
Techs support (templates, transpilers) yes server-side preprocessing (e.g. w/ gulp), client-side may be hindered

(*) = I guess so

There is an organisation on github called bem-incubator.

And this organisation is joined by more and more BEM community developers who uses BEM technology inside their projects and wants to develop technology together with us and maintain it together.

There are some recent projects:

  • ng-bem-components by @Guria — it's a wrapper that helps using bem-components on Angular. You can see how it works here.
  • enb-ng-techs by @Guria as well provides technologies ng-annotate and ng-templates to build Angular-powered projects with ENB.
  • bem-flux by @sameoldmadness — its realisation of FLUX paradigm for bem-core.
  • html2bemjson by @tadatuta allows converting HTML code to BEMJSON. New version of the package was baked recently.
  • @awinogradov baked major release bem-grid 2.0.0 in the frames of which grid has moved to using lost.
  • bem-scrollspy by @kompolom — its realisation of scrollspy on i-bem.js.

If you have useful tools and libraries based on BEM technologies, join our BEM incubator!

Here are some latest links that we have found on the topic:

  • React BEM helper by Marco Hamersma (@marcohamersma) from Berlin.
  • BEM classnames by Hayato Mizuno (@pocotan001) from Tokyo.
  • React BEM by Cuzzo Yahn (@cuzzo) from LA.
  • bem-cn from Alexander Burtsev (@albburtsev) from Moscow.
  • b_ by Mikhail Davydov (@azproduction) from Berlin.
  • Flexible Grid System BEM CSS by Doğukan Güven (@dnomak) from Turkey.
  • A PostCSS plugin to lint BEM-style CSS by Nicolas Gallagher (@necolas) from San Francisco (Twitter) and David Clark from Turkey.
  • BEM Constructor by Daniel Guillan (danielguillan) from Barcelona. It's a Sass-library that gives you syntax sugar to describe independent objects in BEM style.
  • _bemify — Sass mixens that help you to write .scss in BEM style, by Franz Heidl (@franzheidl) from Berlin.
  • Front-end Elements Dictionary or a set of popular naming for classes in BEM style by Vladimir Rodkin from Saint Petersburg.
  • GETFLAT — demo project build on Angular-BEM + LESS and Gulp by Vladimir Titsky (@catindev) from Karaganda.
  • bnsf framework by Alexander Savin (@apsavin) migrated to ENB build.

Add yours in comments!

There was a thread recently in Russian on using BEM in medium-sized projects written by Nikolay Gromov who complained that writing BEMJSON requires more time than writing HTML with a help of emmet.

I don't feel the same way about time spent on writing code not in percentage relating to time spent on debugging and thinking over not in absolute terms but I thought that spending time for writing analogue for emmet for BEMJSON is good enough task to spend an evening.

It is how this package bemmet emerged that can expand abbreviations like b1>__e1*2>b3_theme_islands+_state_active{hello} into BEMJSON:

    block: 'b1',
    content: [
            block: 'b1',
            elem: 'e1',
            content: [
                    block: 'b3',
                    mods: { theme: 'islands' },
                    content: {}
                    block: 'b1',
                    mods: { state: 'active' },
                    content: 'hello'
            block: 'b1',
            elem: 'e1',
            content: [
                    block: 'b3',
                    mods: { theme: 'islands' },
                    content: {}
                    block: 'b1',
                    mods: { state: 'active' },
                    content: 'hello'

Using options you can configure custom naming — powered by bem-naming. stringify() method supports indentation options and quotes — powered by stringify-object.

You can try bemmet in action using online demo. You can also install it right away into your editor using plugins for Sublime Text and Atom.

Would be nice if you can commit with plugins for some other editors.

Good luck!

I was wondering why you chose to define an element entirely using classes in the HTML instead of breaking shared functionality into placeholders / mixins (to use Sass as an example). Is it because you don't use a preprocessor?

If we take the example of a list, it might look like:

<ul class="ui-list horizontal-list resource-list gallery-list"></ul>

In this situation, why is this better than a single class:

<ul class="gallery-list"></ul>

With that class composed from placeholders:

.gallery-list {
  @extend %ui-list;
  @extend %horizontal-list;
  @extend %resource-list;

  // Gallery List specific styles

Do you see this as potentially beneficial?

What is the correct way of naming items in a list when the item itself has subcomponents. Is it the case that the item should be classed both as a child block of the list and as its own component? Is the following example correct?

<div class="news-feed">
  <h3 class="news-feed__title">…</h3>
  <ul class="news-feed__list">
     <li class="news-feed__list-item news-feed-list-item">
        <h4 class="news-feed-list-item__title">…</h4>
        <img class="news-feed-list-item__thumbnail">
  1. Any well-known websites use BEM, other than Yandex?
  2. In BEM, each block on a page has their own css file, would this increase the page loading time?

Many thanks!

Добрый день,

Подскажите пожалуйста как производить навигацию между страницами. Так сложилось что мне сначала нужно зайти на url для авторизации и потом зайти на другой где собственно уже и производить тест. Пытался найти есть ли возможность работать в gemini с навигацией в браузере из коробки. Как я понял нету, т.к. в кол бэк возможно передать только actions и find/ Вторым вызовом suite.setUrl() поменять урл на другой не вышло. С нестед сьютами так же не выходит. Возможно я не так их применял ниже код:

parent.setUrl('first url') .setCaptureElements('element'); gemini.suite('first child', function (child) { //this suite captures same elements on different pages child.setUrl('secondUrl') .capture('plain'); Заранее спасибо за любую помощь.

Question from https://github.com/fabm22: Hi, is there some tooling for checking the structure of CSS code following BEM approach and having and some warnings if there are errors? Thanks a lot

I am large

.button {border-radius:5px;}

As you see in the example above i have a block named "button". I want to reuse the block "button" inside another block "button-group".

However when a button is used within a "button-group" block i would like to apply some slight modifications.

  • The left button should have radius only on the left.
  • The middle button should have no radius.
  • The right button should have radius on the right only.

How should I do this? The straight forward way for me would be:

.button-group .button {border-radius:0;} .button-group .button:first-child {border-left-radius:5px;} .button-group .button:last-child {border-right-radius:5px;}


1. Naming convention

In terms of convention we used to use dashes as word separators, two underscores to separate elements and one underscore for modifier and it's value:

  • block-name
  • block-name__some-elem
  • block-name_mod-name_mod-value
  • block-name__some-elem_elemmod-name_elemmod-value

But it worth nothing to use any other style. We even have special library to abstract from naming.

More about naming convention: https://github.com/bem/bem-naming#custom-naming-convention

2. Going beyond naming convention

Naming convention is important but UI component is more than just a piece of CSS.

All methodologies for CSS could be considered as a subset of BEM. But they tell nothing about how to implement other pieces: JS, templates, images, specs, documentation (and its translation to different languages), etc.

BEM as methodology does.

3. Component approach

Actualy it's not something absolutely unique nowadays. We already have Web components as a standard speaking almost about the same:

  • Split interface into independent blocks
  • Each block knows everything about itself and hides it's inner implementation
  • Declarative way to describe components

All these questions are solved in BEM without any polyfills. But what's much more important all these things are easy to use and tested in production on a lot of services with a really huge scale (in all sences of this word).

4. What's inside

4.1. DOM abstraction

DOM is too low level thing. It's like an assembler for browsers. We need to provide developers with high level abstraction. In BEM it's called BEM tree.

CSS and JS implementation of the block and it's templates work with it's elements. And for other blocks we provide API to work with.

So instead of waiting for shadow DOM roots to grow we just use current DOM tree for inner implementation of components.

4.2. Mixes

Mixes is a concept of having few different entities on the same DOM node. That gives a possibility to separate semantically different code:

<div class="header__user user link"> — it's simultaneously user element of a header block, user block itself and also a link to use profile.

4.3. File system

Each block get's it's own folder. And all techs of the block — their own files. Modifiers and elements may also be separated into different folders to provide possibility to build just the parts files we need.



4.4. Build

BEM tree works as a declaration to build final runtime upon.


Consider following BEM tree:


or the same in JS:

    block: 'page', content: {
        block: b1, content: {
            elem: 'e1'

Now we can collect all the entities mentioned in this declaration to get all the files from block folder and concat them together.

4.5. Levels of redefinition

With such approach we can build entire library of components for all the purposes (and we actualy did ;)

But it's impossible to meet all the needs. So end users will face situation when they need to change something. Of course they always may edit the source of the library, add modifiers and mix new blocks to old ones to make them look and work as they need. But first option result in a pain when you are to update library version and others require quite a lot of efforts.

But because of declarative nature of blocks implementation we can just put our code in our own block folder and ask build system to concat files from there after library files:

                .b1 { width: 100px; color: red; }
                .b1 { color: green; }
                @import url(../../../library/blocks/b1/b1.css);
                @import url(../../blocks/blocks/b1/b1.css);

So we end up with b1 which is still 100px wide as in library but is green according to our company guidelines.

Absolutely the same approach is used for JS and templates. So developer may get some levels (layers) from a list of block libraries, decide which levels are needed for particular project, then add some specific code on project's level and update source libraries as easy as run bower update.

5. Implementation

At Yandex we implemented and open sourced a full stack of tools written in node.js to work with BEM methodoly as well as JS framework (it uses jQuery under the hood) and template engines operating in BEM terms and some block libraries on top of it.

Quite a lot of companies in CIS in addition to Yandex are already using it and we can confidently say there's no interface tasks which can not be splited into blocks-elements-modifiers.

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!