BEM Relationships

I know bem is pretty hot right now, but I think for a good reason. We’re specifically decoupling components for reuse in a modular fashion and ensuring relationships have meaning. This approach ensures that everyone participating in the development of a website is working with the same codebase and using the same terminology. Here’s a short explanation on how to author bem correctly specifically in a parent/child relationship.

It started with a Skype chat between Hugo and I. I’ve been so confused on how to express children of a parent within a primary parent. I guess my brain went berserk and started making up long selectors like news__header__title and so on to express that news__header__title was a child of header that was a child of news. As you can see by my result I’ve been smoking something super heavy to go in that direction. I’ve been doing it all wrong and here’s how you should be doing it if you’re in the same boat as me.

<article class="news">
  <!-- If you have something very specific to the .news__header component, 
       you should create a new block, like this. -->
  <header class="news__header  header">
    <h1 class="header__title">Title Text</h1>
    <span class="header__close">&times;</span>
  </header>
  <p class="news__content">News</p>
</article>
Codeshare between Hugo and I about proper BEM relationship contexts

Just like the HTML comment in the code example states; If you have something very specific to the .news__header component, you should create a new block element name entirely. This way we can express children who’s parent is specific to .header and avoid the long selectors like I had previously. If you want a further explanation on BEM naming then give this CSS Guidelines doc by Harry Roberts a quick scan. As always, if something isn’t clear let me know in the comments or hit me up on Twitter. May the bem be with you.

Dennis Gaebel

Design Technologist passionate for Open Source, SVG, Typography, Web Animation, Interaction Development & Pattern Based Design. http://droidpinkman.io.
  1. ❧ @svinkle shouted:
    2015/01/05 • 7:46 pm

    .header seems too generic and could be used elsewhere. I’d have .news__header-title, .news__header-close to help with scope.

    1. That’s a really great point Mr. Vinkle. Do you think the way I have posted is still useful in cases where scope is a non issue? Any other examples you’ve used recently to share?

      1. ❧ @svinkle shouted:
        2015/01/12 • 3:33 pm

        When is scope a non-issue? You never know when and/or if someone else will pick up the project one day. Or, your future self will need to add something new. What then? It’s very possible you forget what you wrote a year ago and BAM, conflicts and fires to put out.

        Okay, that was a bit dramatic but you get my point. Always try to write future-proof code, because why not?

    2. I thought exactly the same when writing this example. It was meant to be quick and dirty. .header is definitely too generic, indeed.

  2. ❧ Monika shouted:
    2015/01/06 • 2:27 am

    2 cents since I like BEM debates!

    “If you have something very specific to the .news__header component…”

    The way I’ve approached it, much of BEM naming depends on what makes a specific component unique. If news__header had something distinct about it, independent of the fact it was a child of news, then yes, I’d give it a special class (eg. some-special-header), and maybe forgo the news__header class altogether. If it’s a special header only because it’s inside of news, then news__header alone should suffice. As for the title, is it being styled specifically because it’s in the header, or because it’s in news? eg. maybe news__title would do the trick? Otherwise, I may actually lean towards news__header__title, because to me, part of BEM’s goodness is how explicit it is, even if class names get hairy. phew!

    1. Thanks for the hot debate action Monika. Love me some #hotdrama.
      Something with news__header__title felt a bit too verbose to me when I wrote it in that fashion. I guess I felt I was being far too explicit at times.

      1. ❧ @svinkle shouted:
        2015/01/12 • 3:41 pm

        I used to write classes like this until I read something at some point that made me realize: class names do not need to reflect the dom. Instead of .news__header__title I’d write .news__header-title. You could think of it like .block__element-name instead of .block__element__element.

        It all comes down to preference, I suppose.

  3. ❧ Markus Pint shouted:
    2015/04/18 • 2:25 pm

    The article is spot on. Exactly my thoughts when using BEM.

    Very quickly I started ending up with classes such as .b-notifications__item__icon. With scalability always on my mind it makes me wonder what would happen if I were to add a few more levels of nesting.

    I use Sass to write my CSS and even with 4-5 levels of nesting the code already becomes hard to read. Therefore I avoid excessive specificity the same way Mr. Vinkle does.

    .b-notifications__item-icon as the maximum. (3 levels)

Leave a Reply

Your email address will not be published. Required fields are marked *

show formatting examples
<pre class="language-[markup | sass | css | php | javascript | ruby | clike | bash]"><code>
…code example goes here…
</code></pre>

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comment Preview

  1. John Doe shouted this comment preview:
    2015/01/05