Пример:

<div class="block-name">
   <div class="block-name__item">
      <div class="block-name">
         <div class="block-name__item">
            etc.
         </div>
      </div>
   </div>
</div>

<div class="popup popup_A">
      <div class="popup__container">
        <div class="popup__header">
          <div>Знакомства</div>
          <div class="popup__close">x</div>
        </div>
        <div class="popup__content enabled-notification">
          <div class="enabled-notification__title">Включить уведомления</div>
          <div class="notification">
            <div>
              <div class="notification__title">Новое сообщение</div>
              <div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
            </div>
            <div class="notification__icon">
              <svg xmlns="http://www.w3.org/2000/svg"></svg>
            </div>
          </div>
          <div class="enabled-notification__text">
            Вы разрешаете нам отправлять уведомления о новых сообщениях, комментариях на ваши заметки и т.д.?
          </div>
        </div>
        <div class="popup__footer popup_A__footer">
          <button class="btn btn_color_grey popup_A__btn">Нет, спасибо</button>
          <div class="divider"></div>
          <button class="btn btn_color_blue popup_A__btn">Включить</button>
        </div>
      </div>
    </div>

Блок "popup" ре-используемый, может содержать различный контент. Блок "enabled-notification" уникальный и не будет ре-использоваться. Блок "notification" ре-используемый, может содержать различный контент, в рамках определённых элементов.

Для модификации кнопок (нужно было сделать ширину в 50%), используем микс с модификатором popup_A. В обычном состоянии у "popup" есть только одна кнопка.

.popup_A__footer{
  display: flex;
  justify-content: space-between;
}
.popup_A__btn{
  width: 50%;
}

Ещё есть вопрос по использованию "пустых" тегов-элементов (без классов), допустимо ли это?

<div class="notification">
            <div>
              <div class="notification__title">Новое сообщение</div>
              <div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
            </div>
            <div class="notification__icon">
              <svg xmlns="http://www.w3.org/2000/svg"></svg>
            </div>
          </div>

Привет. Есть вот такой футер:

который можно разделить на два больших элемента:

И получается такая структура:

footer
  footer__wrapper
    footer__item footer__item_columns
    footer__item footer__item_info

Это правильная структура и названия?

И еще внутри есть такие колонки:

И как лучше всего сделать колонки? Сделать их блоками или элемантами? Как тогда лучше обозвать их? Была идея navbar-column, но в колонке может не быть navbar(последняя колонка). Или сделать это элементами футера? Но тогда слишком много зависимости от футера будет и плюс хочется использовать класс wrapper для колонки примерно так:

noname-column
  noname-column__wrapper
    noname-column__header
    noname-column__content

        <div class="infg">
            <div class="infg__item">
                <div class="infg-icon">
                    <img src="/images/implant.svg" class="infg__icon" alt="">
                </div>
                <div class="infg__desc">
                    <div class="infg__title"></div>
                    <div class="infg__text"></div>
                </div>
            </div>
        </div>

Вопрос: правильно ли я сделал именование классов согласно БЭМ? Как будет правильно назвать класс 'infg-icon' который находиться в div`?

Блоки и темы оформления.

Уже давно пытаюсь избавиться от боли модификатора _theme у блоков. У нас 2 темы блока button - публичная и админка, около 2K строк стилей в сумме.

Имхо, блок должен быть максимально реиспользуемым и не тянуть ненужный код. Сейчас под тему запихиваются ВСЕ комбинации модификаторов блока, даже если они не нужны на странице. Это боль в поддержке.

Очень близки идеи http://whitepaper.tools/. В целом работаю тоже в этом направлении.

На данный момент пришёл к использованию 2-х видов переменных.

1. Глобальные/Контекстные (что реализовано в whitepaper)

Задаются через блок theme и модификаторы theme_color_* theme_size_* и т.д. Провайдят контекст переменных вниз по дереву.

.Theme_color_light {
  --color-bg: #f7f7f7;
  --coloron-bg: #222; 

  --color-primary: #222;
  --coloron-primary: #fff;

  --color-secondary: #777;
  --coloron-secondary: #ddd;

  --color-surface: #fff;
  --coloron-surface: #222;

  --color-error: #d00;
  --coloron-error: #fff;

  --color-success: #090;
  --coloron-success: #fff;
}

2. Локальные (Уровень блока)

Задаются с указанием префикса имени блока. Такой способ явно ограничивает пространство имён переменных, чтобы случайно не сломать что-то внутри дерева. И позволяет легко изменять их через модификаторы.

Если спроецировать на мир React, то контекстные переменные - это пропсы, локальные - стейт :)

.Button {
  --Button-bg: var(--color-bg);
  --Button-border: var(--color-secondary);
  --Button-color: var(--color-primary);
  --Button-shadow: var(--color-bg);
  --Button-fontSize: 1rem;

  background: var(--Button-bg);
  border: 1px solid var(--Button-bg);
  color: var(--Button-color);
  padding: 1em 2em;
  font-size: var(--Button-fontSize);
  transition: .3s;
  border-radius: 3px;
}

.Button:hover {
  background: var(--Button-color);
  color: var(--Button-bg);
  cursor: pointer;
  box-shadow: 0 10px 20px var(--Button-shadow);
}

.Button_disabled,
.Button_disabled:hover {
  background: #ddd;
  border-color: #ddd;
  color: #999;
  cursor: default;
  box-shadow: none;
}

Блок получает переменные из контекста и преобразует их в локальные для дальнейшего использования в своих стилях.

3. Модификаторы

Дальше через модификаторы жонглируем уже локальными переменными блока.

.Button_color_action {
  --Button-bg: var(--color-action, #00a);
  --Button-color: var(--coloron-action, #fff);
}

.Button_color_error {
  --Button-bg: var(--color-error, #f00);
  --Button-color: var(--coloron-error, #fff);
}

.Button_color_success {
  --Button-bg: var(--color-success, #090);
  --Button-color: var(--coloron-success, #fff);
}

Данный подход позволяет избавиться от длинных селекторов в css.

Например если мы не хотим использовать локальные переменные, то нужно писать классы таким образом

.Button_color_success {
  background: var(--coloron-success, #fff);
  color: var(--color-success, #090);
}

.Button_color_success.Button:hover {
  background: var(--color-success, #090);
  color: var(--coloron-success, #fff);
}

И это только 2 состояние, а там ещё N состояний, включая вложенные элементы...

Локальные переменные, конечно не серебренная пуля и каскады писать придётся. Но как решение вполне может помочь добиться лаконичных селекторов.

4. Именование цветов

После долгих ресёрчей толком не нашёл способа лаконично и предсказуемо описывать переменные. Наиболее лаконичным стилем нашёл подход из Material Design https://material.io/design/color/

В кратце, есть какой-то цвет и для него создаётся рекомендуемый контрастный цвет.

:root {
    --color-primary: #000;
    --coloron-primary: #fff;
}

В качестве дополнительного задания контраста есть идеи использовать доп. параметр -low, -hight

:root {
    --color-primary: #000;
    --coloron-primary: #dddddd ; /* например для текста на фоне с цветом primary */
    --coloron-primary-hight: #ffffff; /* сильноконтрастный цвет */
    --coloron-primary-low: #777777; /* слабоконтрастный цвет */
}

В целом такое именование позволяет добиться предсказуемых результатов при создании темы.

Правда это тоже не является серебренной пулей, т.к. где-то могут не использоваться рекомендуемые переменные.

.Block {
   background: var(--color-surface);
   color: var(--color-error);
}

И не известно на сколько в новой теме surface и error будут контрастны друг к другу.

upd Пересмотрел ещё раз whitepapper https://github.com/whitepapertools/whitepaper-portal/tree/a6bb170522b470560e3572856cf11b1929e1469a/common.blocks/theme

Идёт разбитие цветовой темы на 2 вида. 1 базовые цвета страницы, 2 контролы (кнопки, чекбоксы, инпуты и т.д.).

Данный подход позволяет наиболее однозначно разрабатывать цвета для темы и тестировать их в "вакуме", что очень удобно. Тема не рассчитывается на все цвета радуги. Если нужно много вариаций, то стоит сделать несколько тем, что и плюс и минус.

Плюсы:

• Однозначность использования цветов
• Возможность разрабатывать тему "в вакуме"

Минусы:

• Нужно использовать несколько миксов темы на странице для нескольких комбинаций цветовых решений.

5. Старые браузеры

Любимый IE... Хоть поддержка по caniuse уже > 90% https://caniuse.com/#search=css-variables он ещё живёт...

Как один из подходов решения этого вопроса есть компромиссный вариант - делать версию с одной темой. Все переменные темы дублировать в :root и через postcss ставить статичные значения.

Этот сегмент получит сильно урезанный вариант оформления... Если это сильно критично то от локальных переменных придётся отказаться и делать стилизацию через каскады.

Либо использовать подходы с css-in-js... Но они не лишены недостатков.

6. Дизайнеры, разработчики и система

Тут конечно есть конфликт интересов... Но имхо, у дизайнера должна быть система, по которой он работает и она должна быть логичной (например http://whitepaper.tools/)

П.Н. Небольшая демка "на коленке" Буду благодарен, если поделитесь своей системой стилизации блоков и именованием переменных.

К примеру есть блок Collapse, у него существует два элемента: Collapse__part & Collapse__item.

На момент инициализации блока хочу разбить его контент таким образом:

//- Из такой структуры (так определено в bemjson)
<div class="collapse">
  <div class="work collapse__item">...</div>
  <div class="work collapse__item">...</div>
  <div class="work collapse__item">...</div>
</div>

//- В такую (модифицировать)
<div class="collapse">
  </div class="collapse__part">
    <div class="work collapse__item">...</div>
    <div class="work collapse__item">...</div>
  </div>
  </div class="collapse__part">
    <div class="work collapse__item">...</div>
  </div>
</div>

C условием того что эти чанки могут быть разной длины(настраиваемый параметр), в данном случае длина составляет 2 элемента(Collapse__item)

Посоветуйте пожалуйста в какой технологии это лучше сделать (в js, bemhtml.js или иным способом), каким образом?

ps. полностью использую среду разработки BEM (rep.: Project-Stub)

Здравствуйте. Подскажите пожалуйста, может ли быть так: Есть блок “родитель”, внутри него есть еще один блок “потомок” и внутри блока потомка есть элемент блока родителя? То есть вот так.

<div class=”parent”>
    <div class=”children”>
      <div class=”parent__elem”></div>
    </div>
</div>

Подскажите как решается данная проблема? У нас имеется класс "header__search-form" который допустим имеет отступ с низу, но как быть если придется перенести блок "search-form" в другое место где ему тоже нужны те же свойства, нужно создавать новый класс для нового окружения, каскадом, добавлением утилитарного класса или как то иначе? вижу 3 варианта

Вариант 1

<div class="header">
    <div class="search-form header__search-form"></div>
</div>

<div class="sidebar">
    <div class="search-form sidebar__search-form"></div>
</div>

<div class="blog">
    <div class="search-form blog__search-form"></div>
</div>

.header__search-form{
    margin-bottom:10px;
}
.sidebar__search-form{
    margin-bottom:5px;
}
.blog__search-form{
    margin-bottom:10px;
}

Вариант 2

<div class="header">
    <div class="search-form mb-10"></div>
</div>

<div class="sidebar">
    <div class="search-form mb-5"></div>
</div>

<div class="blog">
    <div class="search-form mb-10"></div>
</div>

Вариант 3

<div class="header">
    <div class="search-form"></div>
</div>

<div class="sidebar">
    <div class="search-form"></div>
</div>

<div class="blog">
    <div class="search-form"></div>
</div>

.header .search-form {
    margin-bottom:10px;
}
.sidebar .search-form {
    margin-bottom:10px;
}
.blog .search-form {
    margin-bottom:10px;
}

Стандартная ситуация

<body class="body body_fixed">
   <div class="logo">
      LOGO
   </div>
</body>

.logo {
   font-size: 40px;
}
.body.body_fixed .logo {
   80px;
}

Как мне такого рода CSS по папочкам разложить? Как посоветуете наименовать файлы? Что вообще можно сделать чтоб это грамотно сопровождать и deps какой и куда прикладывать. Решил упороться на сборщиках и правильной организации структуры. Настроил сборщики начал тесты проводить потом бац, а что делать со спецефичностью? Хочешь не хочешь но есть моменты когда от неё не уйти.

Добрый вечер. Подскажите пожалуйста, правильно ли организована разметка по БЭМ? Внешняя геометрия и позиционирование блока, а именно padding, position и т.д задаётся через миксы .top-bar__top-lang, .top-bar__top-phone, page__header, footer__copyrights, header__navigation, page__wrapper. Все ли я правильно понял? Можно ли упростить/добавить что либо DOM-узлах?

<body class="page">
    <div class="wrapper page__wrapper">
        <div class="top-bar page__top-bar">
            <div class="top-bar__container">
                <div class="top-bar__row">
                    <div class="top-lang top-bar__top-lang">
                        <ul class="top-lang__list">
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                        </ul>
                    </div>
                    <div class="top-phone top-bar__top-phone">
                        <!-- START .top-phone__list -->
                        <ul class="top-phone__list">
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link">p</a>
                            </li>
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link"></a>
                            </li>
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link"></a>
                            </li>
                        </ul>
                    </div>
                </div>
            </div>
        </div>
        <header class="header page__header">
            <div class="navigation header__navigation">
                <nav class="navigation__container">
                    <ul class="navigation__list">
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                    </ul>
                </nav>
            </div>
        </header>
        <footer class="footer page__footer">
            <div class="copyrights footer__copyrights"></div>
        </footer>
    </div>
</body>

Приветствую, начинаю изучать БЭМ столкнулся с такой проблемой, как правильно именовать элементы при большой вложенности? Пример:

<div class="profile">
        <div class="profile__slider">
            <div class="profile__slider-slide">
                <div class="btn profile__slider-slide-btn"></div>
                <div class="message profile__slider-slide-message" ></div>
            </div>
            <div class="profile__slider-slide profile__slider-slide_something">
                <div class="btn profile__slider-slide-btn"></div>
                <div class="message profile__slider-slide-message" >
                    <div class="profile__slider-slide-message-bold"></div>
                </div>
            </div>
        </div>
    </div>

Можно использовать данное именование: profileslider-slide-message, которое говорит что это элемент "message" является потомком элемента "slide", который является потомком элемента "slider", который является элементом блока "profile". В данном случае profileslider-slide-message также является элементом блока "profile", хотя это не совсем логично, но обеспечиваться локализация данного элемента, в том плане что он будет уникальным.

Здравствуйте.

Как применять методологию bem с bootstrap-scss при верстке макета ? Меня интересует способы применения какие они есть и какие задачи решает каждый из этих способов.

Вопрос 1: Предположим имеется какой-нибудь блок карты (card), который в принципе может переиспользоваться в других проектах. Но в разных проектах разные размеры шрифтов. Каким образом поступить: задавать какой-то размер по-умолчанию (например подходящий для текущего проекта) или создавать модификаторы для размеров (или еще как-то)?

Вопрос 2: Предположим есть блок кнопки (button), и в разных местах одного и того же проекта ему задаются разные размеры, это все нужно задавать через модификаторы?

Вопрос 3: Иногда требуется задать отступы от одного блока до другого, как это лучше реализовать (через модификаторы)?

Вопрос 4: Одна и та же кнопка в разных проектах имеет некоторые различия во внешнем виде, но часть стилей одинаковая, в стиль блока запихнуть только общее, а остальное сделать через модификаторы (_theme_a, _theme_b)?

P.S. Новичок в БЭМ, вопросов много, извините.

Знал БЭМ поверхостно - сейчас выделил время чтобы понять полностью. В целом все выглядит логично, кроме миксов. Возьмем пример с описания

<div class="header">
    <!-- К блоку `search-form` примиксован элемент `search-form` блока `header`-->
    <div class="search-form header__search-form"></div>
</div>

Микс header__search-form добавляет некие стили форме поиска. Форма поиска у нас подключается программно модулем. Теперь решили, что форма поиска необходима и в футере. Описываем подключение модуля и там с тем же шаблоном. И у нас (если ни чего не менять) этот микс применится и в футере. Соответственно нам необходимо либо иметь два разных шаблона блока поиска, либо микс выводить по выполнению условия (скажем PHP формирует этот HTML). Что является по сути лишним. Гораздо более логично, понятно и чище будет обойтись без "миксов". Или, точнее, реализовывать их "обычным" способом каскадных стилей.

.header .search-form { color:red; }

Таким образом код блока (включая шаблон) будет абсолютно самостоятелен, в нем не будет необходимости учитывать/проверять контекст, в котором он подключается. Т.е. фраза из статьи

В данном примере мы совместили поведение и стили блока search-form и элемента search-form блока header. Такой подход позволяет нам задать внешнюю геометрию и позиционирование в элементе header__search-form, а сам блок search-form оставить универсальным. Таким образом, блок можно использовать в любом другом окружении, потому что он не специфицирует никакие отступы. Это позволяет нам говорить о его независимости

В реальности действует если только это блок встречается один раз на странице. В противном случае код должен отличаться как раз таки заставляя вписывать эти миксы.

Только начинаю разбираться с БЭМ. Прочитал все что есть на сайте и посмотрел пару роликов, но остались вопросы на самые базовые темы. Вот один из них, касающийся способов модифицирования стилей элементов вложенных блоков:

Предположим, есть блок button:

< div class="button" > < div class="button_ _icon" / > < /div>

.button_ _icon { color: yellow; }

Он является элементом для блока panel

< div class="panel" > < div class = "button panel_ button" > < div class="button _icon" /> < /div> < /div>

Предположим, мне надо поменять цвет у button__icon только в панели, но не задеть его в остальных местах. Как это сделать правильно?

1. Примиксовывать к button_ icon panel _button-icon. Это может привести к изменению кода блока button, если он не подразумевал возможность примиксовывать к иконке другие классы (например, мы используем React), что противоречит БЭМ.
2. Использовать вложенный селектор .panel .button_ _icon { color: red; }. Это увеличивает связанность компонент и зависимость от реализации button'а. Ну и в обоих этих вариантах panel в принципе не должен обращаться да и знать про элементы чужого блока.
3. Добавить модификатор button_ _icon_color_red для иконки. Опять же потребуется изменение кода для кнопки. И реализация сильно усложнится, если вложенность будет бОльшая - например, не во всех панелях у кнопки другой цвет, а только в панелях, которые лежат в header. Прокидывать модификатор через всю иерархию - напрягает. Как правильно?

Обучаю студентов вёрстке по методологии БЭМ. Хочу автоматизировать простейшую проверку именования по методологии: на пркоммит-хук повесить линтер, который будет проверять pug-разметку (ну или компилировать ее в html и проверять уже его) на предмет соблюдения методологии.

Есть какие-то готовые решения, которые у меня не получилось загуглить? В какую сторону смотреть?

Всем привет ! Я только недавно начал глубже погружаться в БЭМ-методологию (до этого использовал только БЭМ-нейминг). Мне очень понравилась эта концепция и хотелось бы полностью внедрить ее в свой воркфлоу. Однако, т.к. у меня недостаточно опыта и я довольно поверхностно знаю JavaScript, мне не хватает знаний чтобы запилить свой "велосипед" для Gulp4 и/или Webpack4. А готовые решения вроде bem-tools, enb и других специфических решений мне не подходят из-за своей перегруженности и как мне кажется сложности. Я не говорю что это так и есть, это справедливо и субъективно лично для меня.

Хотелось бы иметь возможность подтягивать данные в pug-шаблоны из data.json-файла или аналогичного data.js, а также декларативно определять структуру БЭМ-боков с учетом соответствующих зависимостей.

Если совсем коротко, то нужно вот из такой структуры:

app
│   ├── assets
│   │   ├── fonts
│   │   ├── images
│   │   └── libs
│   ├── blocks
│   │   ├── common.blocks
│   │   │   ├── footer
│   │   │   └── header
│   │   │       ├── header.js
│   │   │       ├── header.pug
│   │   │       ├── header.scss
│   │   │       ├── img
│   │   │       └── nav-menu
│   │   │           ├── img
│   │   │           │   └── background.jpg
│   │   │           ├── nav-menu.js
│   │   │           ├── nav-menu.pug
│   │   │           └── nav-menu.scss
│   │   ├── desktop.blocks
│   │   └── touch.blocks
│   ├── pages
│   │   ├── about
│   │   │   ├── about.js
│   │   │   ├── about.pug
│   │   │   └── about.scss
│   │   ├── gallery
│   │   │   ├── gallery.js
│   │   │   ├── gallery.pug
│   │   │   └── gallery.scss
│   │   └── home
│   │       ├── home.js
│   │       ├── home.pug
│   │       └── home.scss
│   └── templates
│       ├── custom.pug
│       └── default.pug

получить на выходе вот такую:

.
├── about.html
├── assets
│   ├── fonts
│   │   ├── font1
│   │   └── font2
│   ├── images
│   │   └── sprites
│   │       ├── png
│   │       └── svg
│   ├── scripts
│   │   ├── about.min.js
│   │   ├── common.min.js
│   │   ├── gallery.min.js
│   │   └── home.min.js
│   └── styles
│       ├── about.min.css
│       ├── common.min.css
│       ├── gallery.min.css
│       └── home.min.css
├── gallery.html
└── home.html

Мне не принципиально на чем делать сборку, будь-то Gulp, Webpack или их совместное использование, главное получить ожидаемый и предсказуемый результат. Надеюсь, я доступно изъяснялся и смог донести свою мысль. Какие будут мысли на этот счет ? :) Заранее всем признателен.

з.ы. Естественно, прежде чем оставлять свой вопрос здесь я шерстил по сети в поисках готовых решений, однако в одних случаях разобраться мешало отсутствие документации, в других - неактуальность самой информации, в иных - не хватало моей профессиональной компетенции. з.з.ы. В Ютубе я натыкался на пару видео, но если честно, изложенная там информация расчитана далеко не на новичков. Пользуясь случаем, хочу попросить ответственных ребят из Яндекса обновить учебные видеоматериалы и записать воркшопы по сборке БЭМ-проектов на Gulp4 и Webpack4 с учетом реалий 2019 года. Я думаю, не одна сотня людей ждет подобного материала. Всем спасибо.

Добрый день. Планируется ли обновлять эту технологию, так как она довольно интересно смотрится, но не поддерживает PostCSS. Если не планируется, то возможно у кого-то есть нечто подобное, был бы благодарен!

Решил создать собственный блок. Назвал его usual. Но при добавлении mod к нему ничего не происходит. Единственное, что применяется - это tag()(). Вот, что я пишу в usual.bemhtml(скрин) Вот что на выходе:

Следую инструкциям описанным в этой статье - https://habr.com/company/yandex/blog/251473/ При сборке и старте проекта(npm start или enb server) возникает ошибка в borshik'е При этом проект собирает все, но при изменении чего-либо в файлах не реагирует и не перезагружает страницу.

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
    at assertPath (path.js:39:11)
    at Object.dirname (path.js:651:5)
    at res.__constructor (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:87:47)
    at new res (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\node_modules\inherit\lib\inherit.js:123:43)
    at res.createFile (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:24:24)

Семантически правильно писать непосредственно в section заголовок. При этом считается, что для блока section нужно использовать тогда, когда ты можешь дать осмысленное название, т.е. по сути класс для section. Но бывают ситуации, когда есть логический блок, но в нем нужно несколько внешних оберток, как в этом случае

<div class="page-main__banner banner">
    <section class="banner__content">
      <h1 class="banner__title">Быстрая доставка цветов</h1>
      <ul class="banner__advantages">
        <li class="banner__advantage banner__advantage--rose">
          Ежедневный привоз свежих цветов
        </li>
        <li class="banner__advantage banner__advantage--ruble">
          Низкие цены за счет больших поставок
        </li>
        <li class="banner__advantage banner__advantage--car">
          Быстрая круглосуточная доставка
        </li>
      </ul>
    </section>
  </div>

Первая обертка - для фона на всю ширину страницы. Второе - собственно информация. Но у меня осмысленное название у обертки получается, а section - это уже по сути элемент блока. Но при этом я не могу сам section выделить в отдельный блок, т.к. фон тоже является частью блока. Извиняюсь, если не понятно написал. И прошу простить, если вопрос глупый.

Дайджест новостей по БЭМ. Выпуск №15

В этом полугодии ребята из команды БЭМ, как настоящие эссенциалисты, решили откинуть все неважное и сосредоточить усилия на первостепенных задачах. Поэтому этот выпуск дайджеста уместился на один экран :)

Итак, главные новости полугодия:

БЭМ и React

Антон Виноградов пожелал всем добра и сообщил, что bem-react-corе v3 влита в master и с этого момента становится основной рекомендованной версией библиотеки для работы с БЭМ в React мире. А вот версии v1 и v2 больше поддерживаться не будут, но еще какое-то время будут доступны в ветках.

Репозиторий bem-react-core переименован в bem-react для соответствия с npm неймспейсом @bem-react, где находятся все пакеты библиотеки.

Инструменты

• Выпустили @bem-react/* пакеты.
• Опубликовали пакет enb-js-browserify в npm. Используйте его, чтобы получить commonJs в своем клиентском коде.

Документация

Обновили документацию к пакетам bem-sdk с живыми примерами в RunKit:

• walk
• naming.entity.parse
• naming.entity.stringify

БЭМ и DESIGN

• Опубликовали первую версию дизайн-системы Whitepaper.
• Собрали портал http://whitepaper.tools.
• Переехали в новую организацию на GitHub https://github.com/whitepapertools.

Все актуальные новости и анонсы ребята публикуют в Telegram канале whitepaper.

Мероприятия

• Провели митап по БЭМ, где рассказали о библиотеке bem-react-corе v3, которая помогает работать по БЭМ-методологии в мире React. На простых примерах показали, как использование библиотеки делает ваши React-проекты гибче и проще в поддержке. Для всех, кто пропустил, мы записали видео.
• Продолжили эстафету встреч для новичков: на этот раз провели два в дневных интенсива. Видео опубликовано на сайте событий Яндекса. Чтобы не пропустить следующий интенсив, подписывайтесь на новости БЭМ-сообщества.

Видео со всех встреч мы публикуем в канале bem.info на YouTube.

Всех с наступающими и наступившими праздниками! Stay BEMed!