I am a big fan of BEM.I am using BEM for all my office and personal projects from last two years.BEM never been a pain in the ass, especially when you work on large projects and large teams. the html looks clean, readable and easily understandable. helps in creating a perfect modularization for style sheets. Helps and tends you to write or develop more modular codes. with the help of sass or less you can make website authoring to a kickass experience.

Most of my friends complained about the underscore and long names which look’s weird, need to type more, lot of bullshit blah blah. but the main benefit I see from my experience

Understanble HTML document
Helps you in writing modular stylesheet
Easy stylesheet maintenance
BEM make you think webpage as composition of components
which helps in creating reusable stylesheets
BEM improves readability in javascript code while dealing with class names.

My biggest benefit that I got from BEM is, it trained me a lot to thinking in modular way. not only css,but also in programming. I can feel the change and the advantages that i gained.I don’t how to explain it, yeah.. its true.

Give it a try.

Peace

This. After couple of projects with BEM (and SASS) I realized that there had been significantly less issues with classnames and conflicts. It’s just one of those things that kind of silently grew on me.

One think I like about it is that I can safely use generic words (block, area, container) as BEM -element names. It really speeds up the development when I don’t have to think new names that much.

And, like many have said here, the @at-root can be removed with new SASS version. Like this:

.lander {
    &__container {
        @extend %container;
    }
    &__area {
        margin-bottom: 24px;
    }
}

This layout could be easily broken by nested block, as block1’s selectors would affect block2 elements.

<section class="block1">
  <article>
    <h1>Hey!</h1>
    <section class="block2">
      <article>
        <h2>Ho!</h2>
      </article>
    <section>
  </article>
</section>

BEM naming may be not that clean and simple, but it guarantees bulletproof incapsulation.

Nick, I strongly disagree. “Premature optimization is the root of all evil.” There is generally far greater risk to a project from unorganized CSS than from unoptimized selectors. Is performance/efficiency something to be aware of and understand? Yes. But it should not be the primary focus. Optimize only when necessary. Unlike most programming languages, CSS is a particularly sensitive software technology in this regard, as it doesn’t provide strong abstraction mechanisms behind which one can hide gnarly optimizations.

That said, there are other ways to optimize presentation than through selectors. Limit use of shadows and transparency. Prefer CSS3 transitions/animations to JavaScript ones. Concatenate stylesheets to reduce HTTP overhead.

Keep in mind that we should also be focusing on the efficiency of our CSS. I would argue that efficiency should trump our ease of development when it comes down to it.

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS

Knappster, I also do the same nesting style (along with Mike) but my naming convention is different.

.Accordion {

    .header {

        &.isRed {
            background-color: red;
        }

        &.isGreen {
            background-color: green;
        }

        &.isBlue {
            background-color: blue;
        }
    }

    .content {
        padding: 20px;
    }
}

Since “Accordion” and every other module class starts with an uppercase class name, I’m free to name a descendant class with any lowercase name since classes are case sensitive.

For more information on this naming convention: http://www.sitepoint.com/title-css-simple-approach-css-class-naming/

I do something similar but with the child combinator in internal selectors. Otherwise, you expose yourself to risk of regressions and selector battles when composing components. E.g. if this Accordion ends up composing an ArticleBlurb, which may have its own __content, then the Accordion’s __content styles will be applied to the ArticleBlurb’s. This is easily addressed with the child combinator:

.accordion {
    > .__header { /* ... */ }

    > .__content { /* ... */ }
}

You lose flexibility of adding arbitrary elements into the Accordion structure, but that’s a feature not a bug. A consistent structure makes components much easier to manage.

Sub element class names always start with double underscore and modifiers with a single dash. I find it’s much easier to read in both the HTML and SCSS, for example:

HTML:

<div class="accordion">
    <div class="__header -red">
        // Header content
    </div>
    <div class="__content">
        // Blah blah
    </div>

    <div class="__header -green">
        // Header content
    </div>
    <div class="__content">
        // Blah blah
    </div>
</div>

SCSS:

.accordion {
    .__header {
        &.-red {
            background-color: red;
        }
        &.-green {
            background-color: green;
        }
        &.-blue {
            background-color: blue;
        }
    }

    .__content {
        padding: 20px;
    }
}

This thread perfectly reveals how developers couldn’t catch BEM conventions right.

Thanks David! I’m only good at canonical BEM naming:

block
block__element
block_modifier_modifier-value
block__element_modifier_modifier-value

Try this:

.navigation {} // block
.navigation__list {} // element
.navigation__list--small {} // modifier of navigation__list
.navigation__item {} // element

@Sergey – You’ve got your elements and modifiers mixed up:

.block {}
.block__element {}
.block--modifier {}

No.

Correct code would be:

.navigation--list {} // list element
.navigation--list__small {} // small modifier of list element
.navigation--item {} // list item element
.navigation--link {} // list item link element