Login with github

Hi! I'm new to BEM, trying to implement with a little project to learn it.

Inside my HTML file i have this code

<main class="game">

    <!-- Choose to play the game or see the highscores -->
    <div class="game__choose">
      <button class="btn" onclick="startGame()">Play Game</button>
      <button class="btn" onclick="showHighscores()">Show Highscores</button>
    </div>
    <!-- Choose to play the game or see the highscores -->

    <!-- Display elements of the game -->
    <div class="game__game-area">

      <div class="game__hud">
          <div id="questions-counter ">
              <h4>Question</h4>
              <h1>0</h1>
            </div>
            <div id="score">
              <h4 >Score</h4>
              <h1>0</h1>
            </div>
      </div>

    </div>
    <!-- Display elements of the game -->

According to the FAQs code should look like this

<div class='block'>
    <div class='block__elem1'>
        <div class='block__elem2'>
            <div class='block__elem3'></div>
        </div>
    </div>
</div>

So, my questions are:

  1. Is the class game__choose ok?
  2. In the class game__hud i have two more divs. Should the name be game__hud-question-counter or hud__question-counter for example?

Hi,

I am making a structure for list that can be reused in other block elements but I have doubts with the nested items. If you make the sublist elements as a block itself, what would happen with its li elements, do you need to name them according with its father block element or they can be generic?

<ul class="list list--default">
    <li class="list--default__item">Lorem ipsum dolor sit amet</li>
    <li class="list--default__item">
        Lorem ipsum dolor <a href="#" title="link title" target="_self">sit amet</a>
        <ul class="list--default-sublist">
            <li class="list--default__item">
                Lorem ipsum dolor sit amet
                <ul class="list--default-sublist">
                    <li class="list--default__item">Lorem ipsum dolor sit amet</li>
                    <li class="list--default__item">Lorem ipsum dolor sit amet</li>
                </ul>
            </li>
            <li class="list--default__item">Lorem ipsum dolor sit amet</li>
        </ul>
    </li>
</ul>

Thx a lot.

Hi,

I'm trying to understand all the scenarios to apply BEM and there is something I would like to clarify in my mindset about this method.

Ok, imagine that you need a btn-group to gather the button / anchor elements in a module. If the module is the father of all, then you might think this btn-group is a child so it would like this "module__btn-group" but what happen with the btn?, and what about if you need that btn-group styles to apply another module?, then you will need to copy the same css rules again and again?. I mean, all the inner elements must have a father block of his own?.

Thanks a lot for the help.

When i first started using BEM, i found it to be really refreshing at how it brings semantic meaning to our CSS. It's so easy at a glance to see what styles will applied to each state, for every block and element.

Nowadays we are all using libraries like styled-components and emotion, all of a sudden it seems like people forgot about the things we learned with BEM and SMACSS. As a result CSS-in-JS that you encounter in the wild is hard to read and reason about.

For example:

const Button = styled.button`
  /* Adapt the colors based on primary prop */
  background: ${props => props.primary ? "palevioletred" : "white"};
  color: ${props => props.primary ? "white" : "palevioletred"};

  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
`;

IMO these methodologies are even more relevant in the component era, particularly with tools like React and Vue. So I had a go at trying to build a library that lets you use BEM in CSS-in-JS and maintain that precious semanticity.

Think of Trousers like styled-components + classnames + BEM, wrapped in a lovely React Hooks API ❤️. Trousers is designed to help you co-locate CSS and JS but opinionated in that it helps you avoid using JavaScript where CSS can take over. It loosely follows a BEM-like methodology, borrowing the concept of Blocks (the component), Elements (the child node you want to apply styles to) and Modifiers (apply styles when your component has particular props or state) to reduce the complexity that normally comes with CSS-in-JS.

Github Storybook

import { trousers, useTrousers } from 'trousers';

const styles = trousers('button')
    .element`
        background-color: ${theme => theme.backgroundColor};
        border: none;
        color: ${theme => theme.textColor};
        margin: 0 10px;
        padding: 10px 20px 14px 20px;

        :hover {
            background-color: ${theme => theme.hoverColor};
            color: rgba(255, 255, 255, 0.8);
        }
    `
    .modifier(props => !!props.primary)`
        background-color: #f95b5b;
        color: #ffffff;

        :hover {
            background-color: #e45454;
        }
    `;

const spanStyles = trousers('button-span')
    .element`
        font-size: 20px;
        font-style: italic;
    `;

const Button = props => {
    const buttonClassNames = useTrousers(styles, props);
    const spanClassNames = useTrousers(spanStyles, props);

    return (
        <button className={buttonClassNames}>
            <span className={spanClassNames}>
                {props.children}
            </span>
        </button>
    );
};

export default Button;

I hope it is useful to you BEM fans out there,

Thanks for reading.

Hi, I'm new to BEM and are refactoring a legacy codebase. I still have trouble deciding which ones are Blocks and which one are Elements.

The docs says that Blocks are for independent stuffs but Elements are for those who are dependent on the blocks.

And to my question:

Suppose I have a card. I currently always use cards inside card-list. However, in the future, I might use cards outside card-list. I don't know if I will ever do such thing or not. Do I make card an element of card-list block, or do I keep them independent, and is there a sort-of rule of thumb to figure this out?

I currently have several different ways of writing it and I wonder which one would be the most BEM-ish.


1

<div class="card-list">
  <div class="card-list__card">
  <div class="card-list__card">
</div>

2

<div class="list list--type-card">
  <div class="card list__item">
  <div class="card list__item">
</div>

3

<div class="card__list">
  <div class="card">
  <div class="card">
</div>

Thank you very much.

Hi! Couldn't find any info about platform dependent code in BEM.

My trouble looks like this: as QA responsible for a huge web-service I would like to minimize risks and test both: mac and windows. But its rather expencive to run all tests. Whith of them look more risky?

is this rule this apply?

To set a block's position relative to other blocks, the best approach is usually to use a mix.

  <nav class="nav-grid">
    <div class="logo nav-grid__logo">
      <h1 class="logo__title">Beginning</h1>
    </div>

    <ul class="menu nav-grid__menu">
      <li class="item menu__item"><a class="item__link" href="#">Home</a></li>
      <li class="item menu__item"><a class="item__link" href="#">About</a></li>
      <li class="item menu__item"><a class="item__link" href="#">Contact</a></li>
      <li class="item menu__item"><a class="item__link" href="#">Products</a></li>
      <li class="item menu__item"><a class="item__link" href="#">Services</a></li>
    </ul>
  </nav>

Here's example:

<div class="rate-calc">
  <div class="rate-calc__internet internet">
    <div class="internet__title">Some title</div>
    <div class="internet__text">Lorem ipsum dolar sit amet</div>
  </div>
</div>

Is it correct BEM usage? Nesting block in a block still seems unclear for me.

Here what I see on BEM site (https://en.bem.info/methodology/quick-start/#introduction):

Create an element If a section of code can't be used separately without the parent entity (the block).

The exception is elements that must be divided into smaller parts – subelements – in order to simplify development. In the BEM methodology, you can't create elements of elements. In a case like this, instead of creating an element, you need to create a service block.

Here is HTML of the page where that text is written:

<ul class="article__list">
   <li class="article__list-item"></li>
   <li class="article__list-item"></li>
   <li class="article__list-item"></li>
   <li class="article__list-item"></li>
   <li class="article__list-item"></li>
   <li class="article__list-item"></li>
</ul>

It's obvious that article__list-item can't be re-used without article__list. Why isn't article__list block then?

In quick start:

Create an element If a section of code can't be used separately without the parent entity (the block). The exception is elements that must be divided into smaller parts – subelements – in order to simplify development. In the BEM methodology, you can't create elements of elements. In a case like this, instead of creating an element, you need to create a service block.

If I name as blockelement1-element2, it doesn't change the truth i create a element of element and blockelement1-element2 must be used under the blockelement1 context. what's more, in BEM name convention, represent the parent-child relationship, element1-element2 break this rule, how can i know the element2 is a child of element1 or a name of element1 if not read the HTML.

best

oja

First of all, I am completely clear on the flexibility encouraged by the BEM team, and understand that no one can establish definitive rules for creating maintainable CSS.

Anyway, that said, for some reason I can't quite get my head around when it might be "BEM-approved" to use element selectors alone.

Here's an example, in this case written in SASS:

%inline-multiline-dl {
  /*Thanks Lea Verou! (multiline def lists: http://lea.verou.me/2012/02/flexible-multiline-definition-lists-with-2-lines-of-css/)*/
    dt {
      //display: inline-block;
      &:after {
        content: ': ';
      }
    }
    dt,
    dd {
      display: inline;
      margin: 0;
    }
}

%multiline-dl {
  @extend %inline-multiline-dl;
  dd {
    word-break: break-word;
    &:after {
      content: '\A';
      white-space: pre;
    }
  }
}

%inline-dl {
  @extend %inline-multiline-dl;
  dt {
    &:before {
      content: '|';
      margin: 0 8px 0 3px;
      position: relative;
      top: -1px;
      white-space: pre;

    }
    &:first-child {
      &:before {
        content: '';
        margin: 0;
      }
    }
  }
}

dl {
  &.dlist--multiline { //or .dlist_multiline
    @extend %multiline-dl;
  }
  &.dlist--inline { //or .dlist_inline
    @extend %inline-dl;
  }
}

The BEM-ish classnames are right there at the end, and are applied to the block-level definition list, only.

It seems to me that in HTML, the dd and dt elements have no meaning outside of a dl and are likely prohibited from being used in that way. So is it still advised to add element classnames to those elements and their selectors, or does it make sense in BEM to leave it basically like this?

While I'm asking, can someone also explain the decision to switch from double-dashes to single underscores for deliniating modifiers? And did the BEM team ever consider the chainable modifier idea proposed in "BEVM?"

Thanks for any responses.

Is any BEM entity allowed to modify any other entity?

Specifically, is an element allowed to modify another entity?

Consider the following example, where a modifier positions another block - in this case, we have a close block for close gadgets on dialogs etc. and a modal block for modal dialogs:

<div class="modal">
  <header class="modal__header">
     Title goes here...
     <span class="close"></span>
  </header>
  <section class="modal__body">
    Content goes here...
  </section>
</div>

The close block itself doesn't have margin/padding/positioning, because we want it to be reusable in different contexts.

In the context of a modal, the close gadget needs to be positioned properly though, and normally I'd just do this:

.modal__header .close {
  position: absolute;
  right: 7px;
  top: 4px;
}

I've been told this goes against BEM, and instead I should add a modal__close element, and mark it up as:

<div class="modal">
  <header class="modal__header">
     Title goes here...
     <span class="close modal__close"></span>
  </header>
  <section class="modal__body">
    Content goes here...
  </section>
</div>

My argument is that the close modal__close combination is meaningless, because:

  1. The modal__close element doesn't work on it's own
  2. If you forget to add modal__close, the close gadget will break the design.
  3. The close block should always and only occur precisely once in a modal__header.

In other words, the close modal__close combination is meaningless since, in the context of a modal, there is no use-case for either close or modal__close without the other.

I'm struggling to understand precisely what BEM is - if it's a naming convention and a set of patterns, the way I understand patterns (as a programmer) is as language used to describe what you've implemented; but not as decision-making drivers that should dictate what you implement.

In the same sense, I feel that BEM naming is valuable as a convention for describing the logical relationships between CSS classes - and shouldn't be viewed as a set of rules that dictate how you structure your CSS.

In fact, for this modal example, I'd like to go even simpler and drop the modal elements:

<div class="modal">
  <header>
     Title goes here...
     <span class="close modal__close"></span>
  </header>
  <section>
    Content goes here...
  </section>
</div>

And just write CSS like this:

.modal > header {
  ...
}

.modal > section {
  ...
}

Again, my argument is that the immediate header and section elements of a .modal are clearly already elements in the HTML sense, and there is no other use-case for header or section elements as immediately children of a .modal except as the header and body elements of that modal.

Overriding these with a modifier, despite the higher specificity, is literally almost the same thing - e.g. this:

.modal--large > header { ... }

Versus this:

.modal--large .modal--header { ... }

I don't understand how either of these is any better or worse, beside the specificity argument, which seems inconsequential here, since you'll need to specify the modifier and target the header element somehow, for any rule that affects anything below it.

In fact, the first option seems like a generally safer choice in a lot of cases, such as, for example, panels within panels:

<div class="panel panel--red">
  <header>...</header>
  <section>
    Some content here, and another panel:
    <div class="panel">
      ...
    </div>
  </section>
</div>

In this example, I'd like to target .panel--red > section to make it red - and this won't and should not affect the color of the nested panel inside it.

Contrast this with:

<div class="panel panel--red">
  <header class="panel__header">...</header>
  <section class="panel__body">
    Some content here, and another panel:
    <div class="panel">
      ...
    </div>
  </section>
</div>

If you target the panel body with a selector like .panel--red .panel__body to affect the color, this will cascade to any nested panel__body elements and override their default color, which is not what was intended.

Bottom line: should you think for yourself and implement your CSS as needed - or should you apply BEM patterns slavishly and set aside your own judgment?

Do my examples go against BEM in any way?

Check the latest update of bem.info!

  • new design
  • new navigation bar

Stay BEMed!

block modification methodology bem 2018-02-05 13-05-11

Another BEM resources lists

Short interview with Sergey Berezhnoy about BEM and its future: https://survivejs.com/blog/bem-interview/

Brief news about the BEM world since the beginning of the year 2017:

  • Libraries
  • BEM & React
  • Technologies
  • Toolbox
  • Documentation
  • bem.info
  • Events

Libraries

bem-core

Released bem-core 4.1.0-4.2.1.

All changes of the releases are described in the CHANGELOG.

bem-core: turbo

jQuery has been removed from the bem-core library. There is not an official release yet, but you can try the release candidate build and send your feedback.

bem-components

Released bem-components 4.0.0-6.0.1.

All changes of the releases are described in the CHANGELOG.

bem-history

Released the 4.0.0 version.

All changes are described in the CHANGELOG.

bem-calendar

Published a new mini-library — bem-calendar. It contains a calendar based on bem-components.

bem-textarea-editor

Published a bem-textarea-editor library that has:

  • An editor block that allows you to write text in Markdown
  • A convenient toolbar (like Github)
  • A preview function to check the post before sending it to the server.

Try the block here.

bem-font-awesome

Published a bem-font-awesome library, that uses Font Awesome with BEM notation and leave all extra styles out of the project.

bem-font-awesome-icons

Published the alternative version of the bem-font-awesome library — bem-font-awesome-icons, where we split the font into separate SVG icons to sent to the client side the usefull parts only.

BEM & React

bem-react-core

Release candidate version — 1.0.0. Lack of useful documentation blocks the official release of the library.

bem-react-components

Actively worked on bem-react-components — the library of blocks for development with React and BEM-methodology. The official release has not yet been published, but most of the blocks have already been implemented.

create-bem-react-app

Continue to create the React project stub create-bem-react-app, which allows with one command to build a React/BEM application with installed dependencies and correct file structure.

Technologies

bem-express

Published the major releases:

  • Updated the libraries versions — bem-core 4.2.1 and bem-components 6.0.1.
  • Switched from Stylus to PostCSS. By default comes the same set of plug-ins like in the bem-components.
  • Implemented an optional livereload. For details see documentation and README file.
  • Achieved acceleration of the build procedure due to the npm-modules.
  • Refused bower for the supply of libraries. Now all dependencies are set through npm in the node_modules folder.

Wrote step-by-step tutorial: Dynamic projects with BEM.

project-stub

Updated bem-core library version to 4.2.1, bem-components — to 6.0.1 and other dependencies.

As an experiment include gulp-bem into the project-stub.

bem-xjst

Released v8.3.1-v8.8.5 versions.

All changes of the releases are described in the CHANGELOG.

Toolbox

bem-sdk

Moved all bem-sdk packages into a monorepo. We eliminated the loop dependencies between the modules and divided components for optimal use on the client side.

Published updated bem-sdk packages. Updated documentation.

Created the @bem/sdk.file and @bem/sdk.naming.file.stringify packages, which allow you to create path to the file using BEM entity declaration, path to the level and file structure scheme.

bem-tools

Released bem-tools 2.0.0 with updated bem-tools-create 2.1.0.

For details see Readme file.

ENB

Released major prestable version of enb 2.0.0-0. Implemented bem-sdk modules into ENB.

enb-bem-techs

Rewrote enb-bem-techs on bem-sdk and released a prestable version 3.0.0-0.

enb-bemxjst

Updated enb-bemxjst to the newest bem-xjst version, which supports an export to the different modular systems.

gather-reverse-deps

Released gather-reverse-deps package, that allows to build inverse dependences.

gulp-bem-src

Released 0.1.0 version with updated bem-sdk.

bem-naming

The bem-naming package moved to the bem-sdk monorepo. A new package name is @bem/sdk.naming.entity.

In addition, now you can use separate packages:

borschik

Released 1.7.0-2.0.0 versions. Have stopped supporting node 0.8.0. and replaced uglify-js with uglify-es to support ES6.

For details see CHANGELOG.

bem-walk

Wrote new README.

bemhint

Released 0.10.0-0.10.1 versions with warnings support. Update supports full backward compatibility with the previous version.

bemhint-estree

Released missing dependencies linter — bemhint-estree. Added ES6 support and wrote wrapper for the linter of bem-xjst.

bemhint-deps-schema

Released a new version of bemhint plugin — bemhint-deps-schema 2.1.0, that checks that the files * .deps.js match the specification. Now bemhint-deps-schema can process not only.json-, but .js files with module.exports.

Documentation

bem.info

Events

I am using BEM for the first time in my latest project, using SASS and I love it. A lot of refactoring going on, however. One thing that I have not solved is the following, very common situation:

I have a block with a modifier, let's say .block, and .block_wide. In .block_wide there are multiple elements that will get minor tweaks depending on what block they are in. For example .block__image has to get a 100% width when the block is .block_wide. How to write this, preferably in scss?

This is the HTML situation:

<div class="block">
  <div class="block__image"></div>
</div>
<div class="block block_wide">
  <div class="block__image" /></div>
</div>

These are some wrong answers I came up with:

.block {
  &__image { width: 50%; }

// Block level modifier
  &_wide {
    &__image { // This does not work because it results in an entirely new class that is not used in the markup
      width: 100%;
    }
  }
}

In the previous "solution" I'm trying to write it the way I would like it to work but obviously it doesn't.

The next solution works but it feels absolutely wrong:

.block {
  &__image { 
    width: 50%;
    .block_wide & {
      width: 100%;
    }
  }

// Block level modifier 
  &_wide {} // Nothing here
}

Now there is no clarity in the source css at all and very quickly this will get out of hand. I'm probably trying to use BEM in a way that it's not meant to be used. If someone could enlighten me on the matter!

Hello,

I was exploring BEM and how could I apply it to my future projects.

Let's say I have 3 widgets, each one containing multiple styles. I name the widgets Card 01, Card 02 and Card 03, they are similar but not the same, some input fields are different and I might create even more, that's why I chose to name them using numbers.

The html looks like this, what's inside card__content is different from a card to another, and the card have about 3 themes, my question is how should I add those differential classes?

<div class="card">
    <img class="card__image">
    <div class="card__content">
        ...
    </div>
</div>

There are few options and I can't decide.

  1. class="card card-01 card_theme_01" .card-01.card_theme_01 {}

  2. class="card card-01 card-01_theme_01" .card-01_theme_01 {}

  3. class="card-01 card-01_theme_01 class="card-01__image

Or I can even turn the elements into blocks, an advance would be really helpul.

<div class="card-01 card_theme_01">
    <img class="card-image">
    <div class="card-content">
        ...
    </div>
</div>

<div class="card-01 card-01_theme_01">
    <img class="card-image">
    <div class="card-content">
        ...
    </div>
</div>

In the BEM documentation, they make reference to something called a "service block":

... In a case like this, instead of creating an element, you need to create a service block.

I can't find any mention of a service block. What does this actually mean?

We are happy to announce the FullStack conference in London. Are you looking for all the latest JavaScript, Node.js and IoT technologies and discover the latest best practices and ideas? You are welcome to the FullStack conference.

This July BEM will be there. Don't think that it will only be about CSS. BEM will present its FullStack platform.

Now is the time of component web. Web Components are actively developing but still have some limitations such as web browsers support. BEM methodology can be applied to any platform and already has implementations which work in all the browsers. It is created as open source software and is suitable for any programming language or any framework.

Let's talk on what do you really know about BEM Methodology and existing BEM Platform. BEM was originated by Yandex more than 10 years ago. It was approved by huge number of large, small and scalable projects, with different developers and changing support teams.

Harry Roberts was one of the first who told about BEM in English speaking world. But he uses only the CSS part of the BEM methodology and doesn't go further. This July at the FullStack conference in London the BEM inventors Sergey Berezhnoy and Vladimir Grinenko will present the Unknown parts of BEM.

4 things you may have missed about BEM methodology:

  • BEM is not only for CSS

BEM is applicable to JavaScript, templates or even native code for mobile apps. In addition to double underscores that changed CSS world, templates and JavaScript written using BEM principles will also significantly change your development process.

BEM has common approach for all technologies: HTML, CSS, JavaScript, docs, tests, etc.

  • BEM has concept of redefinition levels that can work in all technologies

As in CSS, you can change/redefine the appearance of a block, in JavaScript and templates you can change/redefine the behavior of blocks and the layout of tags on a page. The important thing — you do not need to change the initial block implementation, changes will be applied from another redefinition level.

  • BEM has its own file structure & tools

A component-based approach used in the BEM methodology also determines the way that BEM projects are organized in a file structure. In BEM, it's not just the interface that is divided into independent components, i.e. blocks, but the implementation of blocks is also divided into independent parts, namely files.

To ease a work with all BEM components named and stored on a file structure by BEM principles, we created a lot of open source tools.

  • BEM has its own self-titled platform

BEM methodology is simple recommendations for organizing a project that needs to be done quickly, but supported for many years. BEM has a ready-made implementation of these recommendations — BEM Platform — technologies and libraries with open source code.

Want to explore how BEM methodology and platform really work? Join the FullStack conference!

I have a question concerning styles for generic blocks in BEM (for instance .button) vs Media Queries.

The block in BEM (as documentation says) is supposed to have generic styles which will be applicable to all elements on site, let's say I have a ".button" block...

And my button will have reusable styles like:

.button {
    font-family:Verdana;
    padding:30px 20px;
}

The purpose of that generic button is so that if I were to make "another" button, say "welcome button" with different styles I can write modificator button--welcome which will only add additional styles to .button which at the end will look like this:

<button class="button button--welcome"> </button>

This is where Media Queries PROBLEM comes in. Padding defined in my generic .button can be different for different media queries (I am using border-box so padding are internal styles for .button). For instance padding for max-width:480px can be padding: 10px 5px; Does it mean that I should NOT include padding in my generic .button block because .button will no longer be generic? Or, I can do something like this (but I wonder whether it is valid BEM way):

.button {
     font-family:Verdana;
     @media and (max-width: 480px) {
     padding:10px 5px;}
     @media and (max-width: 780px) {
     padding:15px 10px;
     }
     @media and (max-width: 1200px) {
     padding:20px 15px;
     }
     @media and (min-width: 1201px) {
     padding:30px 20px;
     }
}

Also, I've seen some generic .button blocks with the following code:

.button {
  padding: 0.75em 1.25em;
  border-radius: 4px;
  background-color: green;
  color: white;
  font-size: 1em;
  line-height: 1.5em;
  transition: all 0.15s ease-in-out;
}

The issue of generic block styles vs media queries arises in the case of border width, line-height which can be different for different media queries.

I've seen the documentation about external geometry/positioning, but padding is not external geometry: https://en.bem.info/methodology/css/#external-geometry-and-positioning

My issue here is different.

What is your opinion on USING SMACSS STATE CLASSES FOR COMMON MODIFIERS as suggested in this article?

http://sugarenia.com/blog/bem-pitfalls-advice/

We published a new mini-library — bem-calendar. It contains a calendar based on bem-components.

It looks like this: desktop_en

Try our new bem-calendar in your projects!

Hi all,

We are working on a new version of this forum and in the process a bem-textarea-editor library was created. The library has

  • An editor block that allows you to write text in Markdown
  • A convenient toolbar (like Github)
  • A preview function to check the post before sending it to the server.

bem-textarea-editor

It turned out well, so we decided to publish the library as open source. May be it will be useful for you too! :)

Try the block here.

Hello, I just started with BEM and really like it. I just have an issue with the following code and hope someone can help me out.

This is my sample code

<nav class="books">
  <ul class="books__lists">
    <li class="books__items"><a href="/"  class="books__links">Sidebar link</a></li>
  </ul>
</nav>

How I am lost to what the link should really be called? Since the li is under the block of books_lists now sure what the link class should be?! I have a design with a lot of different link styles, so is it better to have something like link-books?

Thank you and keep up the good work. Jim.

How does BEM work with Bootstrap´s .container and .row classes? Say if I have a block called .design-news with a background image that spans the entire page and then a .container and .row under that block which would center my content, can I just keep the default classes or does it have to be .design-news__container and .design-news__row?