Login with github

$ npm install npm WARN EBADENGINE Unsupported engine { npm WARN EBADENGINE package: 'puml-link@0.0.1', npm WARN EBADENGINE required: { node: '0.10' }, npm WARN EBADENGINE current: { node: 'v16.1.0', npm: '7.11.2' } npm WARN EBADENGINE } npm WARN deprecated uuid@2.0.3: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details. npm WARN deprecated node-uuid@1.4.0: Use uuid module instead npm WARN deprecated xmldom@0.1.31: Deprecated due to CVE-2021-21366 resolved in 0.5.0 npm WARN deprecated browserslist@1.3.6: Browserslist 2 could fail on reading Browserslist >3.0 config used in other tools. npm WARN deprecated csswring@4.2.3: Package no longer supported. Contact support@npmjs.com for more info. npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue npm WARN deprecated coa@1.0.3: Please upgrade to 1.0.4 for node 0.10, 0.12, or to 2.0+ for node 4+ npm ERR! code ERR_SOCKET_TIMEOUT npm ERR! errno ERR_SOCKET_TIMEOUT npm ERR! request to https://registry.npmjs.org/vow/-/vow-0.4.16.tgz failed, reason: Socket timeout

If some help tu me to solve this error. Greeting for your working.

There is a common scenario that keeps coming up when I'm designing blocks with complex layouts, which is the need for what I would call "wrapper elements" (and I mean BEM elements). I'd appreciate any help:

Look at the above picture. This is a "course-card" block. Among its elements, there are these two:

.course-card__duration
.course-card__level

Pretty straight-forward so far. Now, in order to achieve the layout that you see there, I would need another element to wrap those two, and its CSS would look something like this:

.course-card__? {
   display: flex;
   justify-content: space-between;
}

Now, the question is, what should such an element be called according to BEM standards?! It's an element that doesn't serve any semantic purpose, it's just there for layout purposes. I could think of the following options:

- course-card__level-and-duration-wrapper (which obviously looks horrible!)
- course-card__basic-info (still not ideal)
- you tell me?

This is not a rare case. I encounter one of these "wrapper element" cases in almost every block I'm implementing. In this same block, you can see in the picture that there is a need for another wrapper element that wraps instructor-avatar and instructor-name. I also couldn't find a satisfactory answer to this question, neither in en.bem.info nor in Stack Overflow or anywhere else, really.

  1. Should we add a "wrapper" or "container" suffix to the names of these kinds of elements?
  2. Should their names be as semantic as possible? For instance "basic-info" in the first example, and "instructor-info" in the second example? And we should avoid words like "wrapper" and "container" as much as possible?
  3. Are there any other guidelines and conventions in general to deal with these kinds of situations?

So, I'd appreciate any guidance. Thanks in advance.

4 years ago

Hi

Hi I am Kylie Deolla You can call me Kylie Nice to meet you guys https://www.playqiu.net/

<div class="block1">
    <div class="block2">
        <div class="block1__element"></div>
        <div class="block2__element"></div>
    </div>
</div>

What's the correct way to name list items using BEM. I've been using #1 below but have seen other websites use other BEM naming conventions.

#1

<ul class="products-list">
    <li class="products-list__item">
        <li class="products-list__item-title"></li>
        <li class="products-list__item-description"></li>
    </li>
</ul>

#2

<ul class="products__list">
    <li class="products__item">
        <li class="products__item-title"></li>
        <li class="products__item-description"></li>
    </li>
</ul>

#3

<ul class="products__list">
    <li class="products__item">
        <li class="products__title"></li>
        <li class="products__description"></li>    
    </li>
</ul>

#4

<ul class="products">
    <li class="products__item">
        <li class="products__item-title"></li>
        <li class="products__item-description"></li>
    </li>
</ul>

#5

<ul class="products">
    <li class="product">
        <li class="product__title"></li>
        <li class="product__description"></li>
    </li>
</ul>

Hello I am new to BEM and I have a question. Can I use two child classes on one element like this? Example:

<div class="prod">
   <div class="prod__col prod__item></div>
   <div class="prod__col prod__item></div>
</div>

First of all, thanks for such an amazing methodology and tools. I'm very happy so far about the results.

Here is a little problem I'm facing.

{
    block: 'menu',
    type: 'red', // NOTICE i'm intentionally defining it as type not as mod
    items: [
        { title: 'BBC', url: 'http://bbc.co.uk'},
        { title: 'CNN', url: 'http://cnn.com'}
    ]
}

My BEMJSON layouts being more abstract makes me more productive. I would like to ignore details like mods, elems and define them "on the fly" with BEMHTML block (re?)definitions.

block('menu')(
    mods()(function() {
        let custom_mods = {}

        custom_mods[this.ctx.type ? this.ctx.type : 'black'] = true; // menu_red, menu_black, etc.

        return Object.assign({}, this.ctx.mods, custom_mods)
    })
)

The possibilities are endless here. Amazing. Just what I wanted...

Except! My dependencies for menu_red are not included now.

Adding red mod to menu.deps.js is not a solution, because this way red is part of the bundle although BEMJSON defines only GREEN.

Is there a workaround? Thanks,

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?
5 years ago

Nested list

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.

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!