RU
heihachi88
heihachi88
14 November 2018

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.

mrttl
mrttl
26 March 2017

Which is better:

<article class="news">
  <div class="news__image">image</div>
   <div class="news__details">
     <h1>News title</h1>
     <p>News story</p>
   </div>
</article>

or:

<article class="news">
  <div class="news__image">image</div>
   <div class="news__details">
     <h1 class="news__details-title">News title</h1>
     <p class="news__details-story">News story</p>
   </div>
</article>

Please note: .news__details-title and .news__details-story have no real style as I already have a base style for all my H1s and P tags, so with BEM, can I just add phantom classes to make the markup look more readable? Or go with the first example? Personally I like option 2...

deser
deser
16 August 2018

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?

liajoy
liajoy
26 April 2018

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.

jaber5842
jaber5842
31 March 2018
Josh68
Josh68
19 March 2018

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.

mindplay-dk
mindplay-dk
7 February 2018

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?

innabelaya
innabelaya
5 February 2018

Check the latest update of bem.info!

  • new design
  • new navigation bar

Stay BEMed!

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

innabelaya
innabelaya
23 January 2018

Another BEM resources lists

innabelaya
innabelaya
15 January 2018
innabelaya
innabelaya
9 January 2018

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

bparticle
bparticle
10 October 2017

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!

There are posts for this query in archive:
Go to archive

Sort

Labels