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">×</span>
</header>
<p class="news__content">News</p>
</article>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.
.headerseems too generic and could be used elsewhere. I’d have.news__header-title,.news__header-closeto help with scope.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?
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?
I thought exactly the same when writing this example. It was meant to be quick and dirty.
.headeris definitely too generic, indeed.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__headerhad something distinct about it, independent of the fact it was a child ofnews, then yes, I’d give it a special class (eg.some-special-header), and maybe forgo thenews__headerclass altogether. If it’s a special header only because it’s inside ofnews, thennews__headeralone should suffice. As for the title, is it being styled specifically because it’s in theheader, or because it’s innews? eg. maybenews__titlewould do the trick? Otherwise, I may actually lean towardsnews__header__title, because to me, part of BEM’s goodness is how explicit it is, even if class names get hairy. phew!Thanks for the hot debate action Monika. Love me some #hotdrama.
Something with
news__header__titlefelt 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.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__titleI’d write.news__header-title. You could think of it like.block__element-nameinstead of.block__element__element.It all comes down to preference, I suppose.
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-iconas the maximum. (3 levels)