{"id":198754,"date":"2015-04-02T06:19:44","date_gmt":"2015-04-02T13:19:44","guid":{"rendered":"http:\/\/css-tricks.com\/?p=198754"},"modified":"2016-03-09T07:08:53","modified_gmt":"2016-03-09T14:08:53","slug":"bem-101","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/bem-101\/","title":{"rendered":"BEM 101"},"content":{"rendered":"

The following is a collaborative post by guest Joe Richardson<\/a>, Robin Rendle, and a bunch of the CSS-Tricks staff. Joe wanted to do a post about BEM, which we loved, and just about everybody around here had thoughts and opinions about BEM, so we figured we’d all get together on it and do it together.<\/em><\/p>\n

The Block, Element, Modifier<\/strong> methodology (commonly referred to as BEM<\/a>) is a popular naming convention<\/em> for classes in HTML and CSS. Developed by<\/a> the team at Yandex, its goal is to help developers better understand the relationship between the HTML and CSS in a given project. <\/p>\n

<\/p>\n

Here’s an example of what a CSS developer writing in the BEM style might write:<\/p>\n

\/* Block component *\/\r\n.btn {}\r\n\r\n\/* Element that depends upon the block *\/ \r\n.btn__price {}\r\n\r\n\/* Modifier that changes the style of the block *\/\r\n.btn--orange {} \r\n.btn--big {}<\/code><\/pre>\n
In this CSS methodology a block<\/strong> is a top-level abstraction of a new component, for example a button: .btn { }<\/code>. This block should be thought of as a parent. Child items, or elements<\/strong>, can be placed inside and these are denoted by two underscores following the name of the block like .btn__price { }<\/code>. Finally, modifiers<\/strong> can manipulate the block so that we can theme or style that particular component without inflicting changes on a completely unrelated module. This is done by appending two hyphens to the name of the block just like btn--orange<\/code>.<\/p>\n
The markup might then look like this:<\/p>\n
<a class=\"btn btn--big btn--orange\" href=\"https:\/\/css-tricks.com\">\r\n  <span class=\"btn__price\">$9.99<\/span>\r\n  <span class=\"btn__text\">Subscribe<\/span>\r\n<\/a><\/code><\/pre>\n
If another developer wrote this markup, and we weren’t familiar with the CSS, we should still have a good idea of which classes are responsible for what and how they depend on one another. Developers can then build their own components and modify the existing block to their heart’s content. Without writing much CSS, developers are potentially capable of creating many different combinations of buttons simply by changing a class in the markup:<\/p>\n
See the Pen BEM example<\/a> by CSS-Tricks (@css-tricks<\/a>) on CodePen<\/a>.<\/p>\n
At first this syntax might seem slower than simply making a new class for each type of button, but this is not the case for several reasons we’ll cover.<\/p>\n
Why should we consider BEM?<\/h3>\n
    \n
  1. If we want to make a new style of a component, we can easily see which modifiers and children already exist. We might even realize we don’t need to write any CSS in the first place because there is a pre-existing modifier that does what we need.<\/li>\n
  2. If we are reading the markup instead of CSS, we should be able to quickly get an idea of which element depends on another (in the previous example we can see that .btn__price<\/code> depends on .btn<\/code>, even if we don’t know what that does just yet.)<\/li>\n
  3. Designers and developers can consistently name components for easier communication between team members. In other words, BEM gives everyone on a project a declarative syntax that they can share so that they’re on the same page.<\/li>\n<\/ol>\n
    Harry Roberts identified<\/a> another key benefit of using a syntax like BEM when he writes about improving developer confidence:<\/p>\n
    This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we daren’t touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS’ globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don’t know what things do any more. People daren’t make changes because they don’t know how far reaching the effects will be.<\/p><\/blockquote>\n
    Likewise, Philip Walton argues<\/a> that this problem can be fixed if enough developers stick to the principles of BEM: <\/p>\n
    While 100% predictable code may never be possible, it’s important to understand the trade-offs you make with the conventions you choose. If you follow strict BEM conventions, you will be able to update and add to your CSS in the future with the full confidence that your changes will not have side effects.<\/p><\/blockquote>\n
    So if developers can work on a project more confidently, then they’re sure to make smarter decisions about how these visual components should be used. This methodology might not be a perfect cure for all these ailments, but it certainly gives developers a standard on which to write better, more maintainable code in the future.<\/p>\n
    Another smart part of BEM is that everything is a class<\/strong> and nothing is nested<\/strong>. That makes CSS specificity very flat and low, which is a good idea<\/a>. It means you won’t end up fighting with yourself over specificity.<\/p>\n
    Let\u2019s take a look at some of the problems with BEM…<\/p>\n
    Problems with BEM<\/del> CSS<\/h3>\n
    Of course nobody will twist your arm if you break from BEM rules. You could still write a CSS selector like this:<\/p>\n
    .nav .nav__listItem .btn--orange {\r\n  background-color: green;\r\n}<\/code><\/pre>\n
    That looks like it has parts of BEM going on, but it’s not BEM. It has nested selectors, and the modifier doesn’t even accurately describe what’s going on. If we did this, we’d be screwing up the specificity flatness that is so helpful with BEM.<\/p>\n
    A block (such as .nav<\/code>) should never override the styles of another block or modifier (such as .btn--orange<\/code>). Otherwise this would make it almost impossible to read the HTML and understand what this component does; in the process we’re bound to greatly shake another developer’s confidence in the codebase. This goes for HTML, as well: what would you expect if you saw the following markup?<\/p>\n
    <a class=\"btn\" href=\"https:\/\/css-tricks.com\">\r\n  <div class=\"nav__listItem\">Item one<\/div>\r\n  <div class=\"nav__listItem\">Item two<\/div>\r\n<\/a><\/code><\/pre>\n
    What’s probably going on here is that an element in a completely unrelated block has the code a developer needed, but the child elements don’t require a .nav<\/code> class as the parent. This makes for an exceptionally confusing and inconsistent codebase which should be avoided at all costs. So we can summarize these problems by:<\/p>\n
      \n
    1. Never overriding modifiers in an unrelated block.<\/li>\n
    2. Avoiding making unnecessary parent elements when the child can exist quite happily by itself.<\/li>\n<\/ol>\n
      More examples of BEM in action<\/h3>\n
      Accordion demo<\/h4>\n
      See the Pen BEM Accordion<\/a> by CSS-Tricks (@css-tricks<\/a>) on CodePen<\/a>.<\/p>\n
      In this example there is one block, two elements and one modifier. Here we’ve can created an .accordion__copy\u2013open<\/code> modifier which lets us know we shouldn’t use it on another block or element.<\/p>\n
      Navigation demo<\/h4>\n
      See the Pen BEM Menu<\/a> by CSS-Tricks (@css-tricks<\/a>) on CodePen<\/a>.<\/p>\n