Опубликовали новую статью по мотивам первого БЭМпа для новичков! Материал будет полезен всем, кто только начинает знакомство с БЭМ и версткой в целом.

Как устроена серверная сторона БЭМа, как с рендерингом на сервере, с ruby, какие трудности при развертывании? Я вот сейчас общаюсь и мне приводят аргумент, что это еще и лишний гемор на сервере с js и нагрузку на сервер увеличивает, что приводит к удоражанию.

Можете показать сайты которые полностью на стеке БЭМа. НЕ ЯНДЕКС, а то при слове БЭМ у всех Яндекс, много датацентров, много бабок на сервера и тп.

Не могу разобраться по описанию в разделе Декларация блока, как примешивать блок (отдельный специально подготовленный миксин?) к элементу или модификатору. Ткните меня, пож., в примеры использования declMixin? В bem-core, bem-components что-то не вижу ничего.

Привет!

Самое время заглянуть в раздел Методология на bem.info!
Мы обновили часть старых документов и опубликовали новые:

• Уровни переопределения
• Способы изменения блока

To be continued...

Существует ли (рассматривается ли) способ организации блоков в рамках одного уровня переопреледния?

Как пример можно рассматривать ситуацию, когда имеется некоторая (предположим) сущность "Report" и все имеющие к ней отношение блоки удобно было бы хранить в одной папке. Поначалу пытался для таких ситуаций использовать отдельные уровни (создаём уровень blocks/Report, в котором храним всё, имеющее отношение к "Report"), но это получается как-то вне концепции и вообще дичь.

Т.е.: возможна ли не плоская, а древовидная структура папок для блоков внутри уровня?

Доброго дня!

Если необходимо сделать переключение цветовых тем на сайте, получается возможен вариант только с наследованием как и без бэм именования? Т.е. задаем body class="theme_blue", и пишем отдельный css в котором все элементы имет родителем body.theme_blue, или с бэм именованием есть другие решения?

Приветствую,

Используем React, а BEM как CSS методологию.

Есть следующая проблема связанная с адаптивным дизайном.

Допустим есть сущность, которая имеет следующие состояния (модификаторы) small, medium и large.

Бывает так, что на всех разрешениях он имеет одно состояние (к примеру, small), но и так, что на одном разрешении одно, а на другом еще какое-нибудь (к примеру, small по умолчанию, а medium на разрешении > 1280px)

У меня пока два способа решения этой проблемы:

• по подобию адаптивных CSS фреймворков - использовать постпрефиксы, например, -xs, -md, -lg. Получается, что если мне нужно, чтобы на разрешении > 1280px сущность имела состояние medium, я задаю ему medium-lg. То есть такая некая надстройка у состояния. Также есть мысли использовать вместо - символ @ (как обозначение, что это именно media query), то есть medium@lg;
• использовать JS - через window.mathMedia рендерить нужное состояние. Именно всю страницу рендерить с нужными состояниями с учетом разрешения, а не конкретно компонент.

Спасибо.

Мне никак не дает покоя 1 вопрос. Если мы вот так опишим блок и модификатор для блока:

.button { color: red; }

.button_color_blue { color: blue }

Затем в HTML укажем class="button button_color_blue". .

Таками образом кнопка станет синей только потому, что стили модификатора в CSS идут после стилей самого блока. Скажите, возможны ли варианты, когда возможно нарушение порядка следования в CSS? Например после обработки минификаторами. Или например препроцессор SASS вдруг конструкцию .block { &--modificator {} } начнет разворацивать в обратном порядке, и напишет в CSS .block--modificator, а уже потом сам .block Ведь как я понимаю тогда все сломается и кнопка будет красной, несмотря на то, что класс модификатора на теге есть. Как можно быть спокойным за все это?

Заранее спасибо.

Есть такой блок: https://monosnap.com/file/pGc1WTU62lxQLYMh65Nb7peD9zaLJJ

Правильно ли я его разметил по БЭМ?

.news
    .news__head
        .section__title.news__title
    .news__content
        .news__column-left
            .news__img-big-wrap
            .news__sub-title
                .news__link.news__link_big
        .news__column-right
            .news__link-wrap
                .news__link.news__link_small
            .news__date

http://take.ms/uRJoh - допустим есть у меня вот такой блок. Только классы я называю так: .news, .news__head, и так далее, короче по БЭМ-у.

А если мне нужно вот эти элементы на скрине стрелками указаны, завернуть в блок-контент. То как его назвать? .news__head__content нельзя же .news__head-content ?

Разрабатываю файловую структуру нового проекта и задумалась, как предпочтительнее. Есть два варианта:

• вынос всех переменных в папку с переменными
• оставить файл с переменными в разрабатываемых блоках

Вариант 1

   scss/
        blocks/
            menu/
                _common     # css menu
            list/
                _common     # css list
            form/
                input/
                    _common # css input
                label/
                    _common # css label
                button/
                    _common # css button
        variables/
            _menu           # variables menu
            _list           # variables list
            form/
                _input      # variables input
                _label      # variables label
                _button     # variables button
            _common         # variables form
    main                    # all variables and css

Вариант 2

   scss/
        blocks/
            menu/
                _variables
                _common          # css and variables
            list/
                _variables
                _common          # css and variables
            form/
                input/
                    _variables
                    _common      # css and variables
                label/
                    _variables
                    _common      # css and variables
                button/
        variables/
            _common              # variables design page
    main                         # all variables and css

Какой из вариантов построения файловой структуры предпочтительнее?

Заранее спасибо за знания!

Здравствуйте. Небольшая дилемма. Есть элемент блока, содержащий еще несколько элементов. Отображение внутренних элементов может меняться в зав-ти от их количества. В итоге у меня 2 варианта:

<div class="block__item1">
<div class="block__item2 block__item2_type_multi">
</div>
<div  class="block__item2 block__item2_type_multi">
</div>
<div  class="block__item2 block__item2_type_multi">
</div>
<div  class="block__item2 block__item2_type_multi">
</div>
</div>

или

<div class="block__item1 block__item1_type_multi">
<div class="block__item2">
</div>
<div  class="block__item2">
</div>
<div  class="block__item2">
</div>
<div  class="block__item2">
</div>
</div>

Второй вариант красивее, но потребует использования в css конструкции типа .block__item1_type_multi .block__item2 {} Как лучше поступить?

PS: если block__item1 смиксовать в блок, то вопрос, в принципе, останется такой же..

Всем привет! Я уже задавал такой вопрос в слаке, но хочу продублировать его здесь, поскольку он очень важен для меня (надеюсь, что и ещё для кого-то окажется полезным), и очень хочется разобраться в нём.

Вопрос опишу так:

Как быть в случае, если, к примеру, нам необходимо сделать адаптивность, скажем, на ширине <=500px. То есть делаем сайт адаптивным на ширине 500 и меньше. Да, я понимаю, что есть медиазапросы. Но что, если у нас, к примеру, есть навигация, в которую на ширине <=500px должны добавляться доп. пункты, а на ширине больше 500px эти доп. пункты должны убираться, и это надо делать с помощью JavaScript.

Проблема в том, что определение ширины в JS не всегда совпадает с определением ширины в CSS-медиазапросах, к примеру, в JS мы достигаем 500px, а в CSS до этой ширины ещё 1-2 пикселя, и следовательно все эти манипуляции с навигацией будут немножко (что уже критично) опережать остальную адаптивность, которая делается (и должна делаться вместе с адаптивностью навигации) с помощью CSS.

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

Например, вот так вот:

.participation margin: 20px 0 30px .js-adaptive & // - вот этот класс вешается на body при <=500px margin: 10px 0 20px

Что скажете?

Хочу добавить стилизацию checkbox и задумалась о корректности Вариант без стилизации

<div class="checkbox-inner">
   <input class="checkbox__control" type="checkbox" id="test">
   <label class="label__control" for="test"></label>
</div>

Стилизация внешнего вида

Вариант стилизации 1
модификатор .checkbox-inner_theme-info

<div class="checkbox-inner checkbox-inner_theme-info">
   <input class="checkbox__control" type="checkbox" id="test">
   <label class="label__control" for="test"></label>
</div>

Вариант стилизации 2
модификатор .checkbox-inner_theme-info модификатор .checkboxcontrol_theme-info модификатор .labelcontrol_theme-info

<div class="checkbox-inner checkbox-inner_theme-info">
   <input class="checkbox__control checkbox__control_theme-info" type="checkbox" id="test">
   <label class="label__control label__control_theme-info" for="test"></label>
</div>

Какой из вариантов предпочтительнее?

Заранее благодарна на помощь!

<form class="form form_flowers">

        <div class="form__group">
            <div class="label-group">
                <label class="label-group__label" for="test">Текст</label>
            </div>
            <div class="input-group">
                <input class="input-group__input" type="text" id="test">
                <span class="input-group__addon">
                    @
                </span>
            </div>
        </div>

</form>

Создаю шаблон, чтобы использовать для создания формы с полями:

• Обычная
• Горизонтальная
• input c кнопкой
• input с иконкой
• Группа кнопок

Сорри, если что не так, не разобралась как у вас тут код как-то без отступов выводится(

Доброе утро. Подскажите, пожалуйста, в случае использования БЭМ в качестве методологии именно для именования классов в своем проекте(без использования bemjs и прочего) является ли обязательным наличие класса у элемента блока, если у данного узла попросту нет никаких стилей? То есть что-то вроде

<div class="block">
<div>
<span class="block__elem"></span>
<div class="block__elem"></div>
</div>
</div>

Доброго времени суток. Столкнулся с БЭМ. Прочел и просмотрел массу материала, но понятнее не стало. Чем дальше в лес - тем больше дров. В связи этим возник ряд вопросов, которые, уж простите, спрошу здесь.

1 - На сколько обязательно писать BEMJSON и использовать инструменты BEM ? то есть суть то какова : я могу писать классы и создавать файловую структуру вручную. Но в таком случае всплывает ряд неудобств : длинные селекторы, долго и не удобно прописывать вручную , в css будет все а не только то что нужно и используется. Получается что самый правильный подход - использовать метод формирования HTML из JSON . Но тут же сложность которая лично меня вводит в ступор : мой мозг напрочь не хочет представлять верстку в виде JSON и сущностей БЭМ . По мимо этого все скрипты придется писать через BEMHTML и это так же немного вводит в ступор ... немного от слова совсем. Возможно есть какой то метод упростить процесс вхождения в БЭМ ?

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

3 - Путаница с папками. Я просмотрел множество туториалов по тому как работать с БЭМ и вынес вывод : свои блоки можно класть и в desktop.blocks и в common.blocks . Однако куда же правильно ? в некоторых туториалах файлы блоков , которые создаются в процессе верстки, кладут в desktop в некоторых в common . При этом никто не объясняет как же все же правильно . (интуитивно чую что в desktop , но это не точно :) )

Заранее прошу прощения за вопрос - возможно некоторые , если не все, покажутся глупыми, но это то что не дает мне спать )

Добрый день. Имею вот такую структуру, скажите, пожалуйста, все ли "по стандарту"? Изучаю методологию совсем не долго, потому корректировки от специалистов бы не помешали. Код упрощен, лишнее удалил, чтобы было удобнее

<form class="form">
   <div class="form__line">
      <div class="form__label"></div>
      <input type="text" class="form__input form__input_m">
      <input type="submit" class="form__button button" name="submit">
   </div>

   <div class="form__line">
      <div class="form__label"></div>
      <input type="text" value="" class="form__input">
   </div>

   <div class="form__line">
      <div class="form__label ">
      </div>
      <input type="text" class="form__input">
   </div>

   <div class="form__line">
      <div class="form__label ">
      </div>
      <input type="text"  class="form__input">
   </div>

   <div class="form__line">
      <div class="form__label ">
      </div>
      <div class="form__complex counter">
         <div class="counter_wrapper"></div>
         <textarea  class="form__input"></textarea>
      </div>
   </div>

   <div class="form__line">
      <div class="form__label "></div>
      <div class="form__complex options">
         <div class="options__box">
            <input type="checkbox">
         </div>
         <div class="options__box">
            <input type="checkbox">
         </div>
         <div class="options__box" > 
            <input type="checkbox" >
         </div>
         <div class="options__box">
            <input type="checkbox">
         </div>
      </div>
   </div>

   <div class="form__line">
      <div class="form__label ">
      </div>
      <div class="form__complex avatar">
         <div class="avatar__info"></div>
         <div class="avatar__meta"></div>
         <div class="avatar__thumbnails thumbs">
            <div class="thumbs__delete"></div>
            <div class="thumbs__crop"></div>
         </div>
      </div>
   </div>

   <div class="form__line">
      <div class="form__label">
      </div>
      <div class="form__complex captcha">
         <div class="captcha__value"></div>
         <div class="captcha__image"></div>
      </div>
   </div>

</form>

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

Т.е., к примеру, есть некий блок, в нем допустим несколько элементов. Блок будет переиспользоваться на нескольких страничках, возможно с изменением положения элементов внутри блока.

Оформление и стили элементов вынес в их модификаторы (по одному для каждой странички), а позиционирование (отступы) сомневаюсь, куда по-науке прописать:

1. или в реализацию (.css) самих элементов, но тогда не совсем понимаю, как сделать универсально для каждой странички.
2. или создать служебные элементы самого блока (опять же по одному для каждой странички) и миксовать их к каждому моему вложенному в блок элементу, но тогда получается микс элемента с элементом по сути, правильно ли это?

Допустим, у меня есть блок навигации, который генерит нужную разметку. Я хотела бы использовать его в шапке и в подвале, но чтобы и там, и там он был элементом: .header__nav и .footer__nav. Сейчас чтобы использовать генерацию разметки я сначала подключаю его как самостоятельный блок ({ block: 'nav'}), а затем, например, с помощью миксов добавляю контекст: mix: { block: 'header', elem: 'nav'}. Вопрос: можно ли как-то делать наоборот, то есть объявлять элемент блока, а потом к нему примиксовывать блок для генерации разметки? Другой возможный вариант использования — SVG-иконки, когда, например, элемент .socials__icon одновременно является инлайновым SVG-изображением. Хочется объявлять элемент блока, а потом указывать какой шаблон использовать для разметки, и, таким образом, избавиться от необходимости привязывать контекст миксинами. Как это можно сделать?

Прочитала про БЭМ, решила попробовать использовать и сразу же натолкнулась на проблему. Допустим, у меня есть блок, внутри него много тегов p, и всем нужно задать определенные маргины. Я пишу:

.my-block p{
  margin: 10px 0;
}

Но есть один тег p, которому я хочу задать другой маргин, я пишу селектор .my-block__my-elem и этот маргин не применяется, потому что селектор .my-block p перевешивает. Что делать в таком случае? Не писать же important, селектор .my-block .my-block__my-elem, или, еще хуже, не добавлять же всем тегам p класс my-block__p?

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

Я вижу следующие варианты:

• Вариант "в лоб" - копипастить структуру страницы (bemjson) из бандла в бандл и менять только область контента. Вообще не вариант т.к. при большом размере проекта не дай бог поменяется структура (например добавили на страницу 3-ю колонку) и придётся бегать по всем bemjson-ам и везде менять структуру.

• Сделать layout в виде блока, а структуру основной области контента пихать в поле content: блока. Это уже вариант, но слабенький, т.к. непонятно тогда зачем вообще bemjson. Весь layout тогда будет в шаблоне блока и в bemjson-е не виден. Плюс непонятно как например для этого варианта ещё и добавить что-то в сайдбар. Вернее понятно - заводим ещё поле в блоке и затем в шаблоне layout-а разруливаем, но это как-то тоже кривенько. Ну т.е. bemjson будет типа:

{ 
  block: 'layout',
  content: { block: 'login-form' },
  sidebar: { block: 'sidebar-widget' }
}

Т.е. фактически выродится, а всё мясо будет фактически внутри шаблона блока layout.

Может есть какие-то ещё варианты? Ну и интересно вообще кто и как подобные штуки разруливает.

Здравствуйте можно ли вкладывать блок в элемент? например пишу так: https://jsfiddle.net/fsj2pczs/

Очень понравилась идея независимых блоков, но возник ряд вопросв: 1) Мне нравится Django, я хочу применять БЭМ в проектах на этом фреймворке, натыкался на пост https://ru.bem.info/forum/483/ , есть ли способы это сделать проще, уже 2017 год.. 2) Непонятно, как организовать взаимодействие компонентов, типа нажал на кнопку "Купить", отреагировала корзина.. Смотрел вебинары, советуют через посредника делать, в общем блоке, но если я перенесу кнопку, и она окажется вне этого посредника, все может поломаться.. 3) Куда складывать библиотеки, типа всяких jqtree и прочих? Как отдельный блок? 4) Как обстоят дела с Angular2? 5) Как сделать так, чтобы с каждой динамической страницей Django, полученной через рендер шаблона, на клиент отдавалась статика, необходимая только для действительно необходимых компонентов Спасибо.

Уважаемые бэмчане,

не сочтите за оффтоп, но хотелось бы услышать ваше мнение. Angular2 и Vue, например, имитируют scoped css через присваивание уникального атрибута всем тегам и добавление его же к селекторам в css. Возникла идея сделать эти трансформации приближенными к бэм методологии. Представьте, что у нашей компоненты шаблон и стили такие:

<section class='product'>
    <header class='title'>
        Foo 
        <span class='hint'></span>
    </header>    
</section>

.product { /* ... */ }
.product .title { /* ... */ }
.product .title .hint { /* ... */ }

Тогда пропустив шаблон и стили через наш преобразователь получим следующее:

<section class='product_ABC product'>
    <header class='product_ABC__title title'>
        Foo 
        <span class='product_ABC__title_hint hint'></span>
    </header>    
</section>

.product_ABC { /* ... */ }
.product_ABC__title { /* ... */ }
.product_ABC__title_hint { /* ... */ }

Принцип прост, по возможности заменить и сделать стили плоскими. Сохранить изначальный селектор Элементов и пройтись по шаблону Добавив новые имена классов. Изначально селекторы всегда вида: BLOCK(…modifiers) ELEMENT(…modifiers) … . Модификаторы мы не изменяем. В следующем примере селектор плоским сделать мы не можем, так как он зависит от состояния родителя:

.product.active .title {}

.product_ABC.active .product_ABC__title { }

Плюсы данного подхода:

• Разработка блока/компоненты не зависит от инструментария, как Css Modules, например
• Все стили после сборки под селекторами с уникальной солью - нет коллизий
• Все селекторы максимально плоские - хорошо для производительности
• Минимальная специфичность селекторов - хорошо для переопределения
• Все изначальные классы в html остаются не тронуты - если вдруг нам нужно искать элементы из js, добавлять модификаторы, или определять новые стили по этим селекторам.

Недостатки:

• Работает в компонентной архитектуре, где шаблон инкапсулирован в отдельный блок.

Дополнительно:

• Можно от соли отказаться, и гарантировать уникальность блоков самому, тогда селекторы всегда будут детерминированны.
• Можно ввести некоторые соглашения об именах на случай каких либо "edge case".
• Можно от имени блока отказаться и генерировать его другим способом, а в стилях использовать ":host" для его стилизации.

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

Всем привет! Мне нравятся иконки Font Awesome, но не нравится подключать файлы расположенные на другом хосте, так же как и копировать все подряд. Это субъективное мнение, можно сказать личное предпочтение. Еще не всегда существуют в одной библиотеке все иконки которые нужны. Принято решение использовать кастомную накопительную библиотеку SVG-иконок. И конечно же использование по БЭМ-методологии. Хочу поделиться мыслями.

Реализация:

1) Каждая иконка является модификатором блока icon cтруктура папок:

    common.blocks/
        icon/
            _rub/
            _search/
            ...

2) На уровне common.blocks в папочках модификатора лежат файлики bemhtml.js, пример icon_rub.bemhtml.js:

block('icon')(
    mod('rub')(
        content()('<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595 776"><defs><style>.icon_color{fill:#201600;fill-rule:evenodd;}</style></defs><title>rub_sign_1</title><path class="a" d="M573.39,118.92c-7.81-20.13-40.26-56.55-52.25-67.71-19.41-18.06-51.76-37.66-80.31-43.69C420.27,2.26,390,0,351.19,0L49.75,2V333.47H.5V440.09H49.75v39.67H.5V588.38H49.75V776H173.18V588.38H445.75V479.76H173.18V440.09H358c83.62-3.76,138.79-26.92,179.17-69.49,35.55-43.21,58.29-80.07,58.29-146.3,0-38.39-10.69-73.76-22.11-105.37ZM450.82,300.59h0c-21.69,24.84-38.48,26.91-91.63,32.88h-186v-226H357.47c35.4,0,57.94,8.26,70.5,12.77,20.52,10.86,26.19,18.07,33.1,25.91,14,23.1,22.84,40.18,22.84,71.79C480.5,266.5,471.37,276.5,450.82,300.59Z" transform="translate(-0.5)"/></svg>')
    )
);

3) На уровне desktop.blocks и пр. в папочках модификатора лежат стили icon_mods.post.css, пример icon_rub.post.css:

.icon_rub svg .icon_color
    fill #333
    stroke #333

.icon_rub svg
    margin 0
    height 21px

@media (--xlarge-only) {
    .icon_rub svg {
        height 19px
    }
}

@media (--large-only) {
    .icon_rub svg {
        height 15px
    }
}

со стилями цвета может перемудрил )))

4) В bundles файлике page.bemjson.js декларируется блок иконки:

{
    block : 'icon',
    mods : { rub : true }
}

Люди, хочется верить что схема идеальная, поправьте - если что не так.

Как быть? Я создал один блок basis В блоке basis создал два модификатора _type_header и _type_footer И сделал я это только для того, что бы в папку блока basis положить общий фон для header и footer Чувствую, что это в корне не верно. Но увы...правильного выхода из этой ситуации не могу найти. Что подскажите, как поступать в таких случаях?

Добрый день.

Осваиваю БЭМ совсем недавно, появился вопрос, ответ на который не удалось найти в доках.

Допустим, имеется простенькая разметка (https://jsfiddle.net/ao3xLbue/) элемента формы .form-el с модификатором label в значении hidden. При этом элемент label скрывается. Теперь эту конструкцию поместили в блок .form, где поведение для .form-el_label_hidden должно быть переопределено. Пусть элемент label при этом становится зелёным, а не скрывается. В голову приходит только каскад .form .form-el_label_hidden .form-el__label { ... }. Как обойтись без него? Может быть какой то хитрый микс придумать, который "залазит" внутрь блока .form-el? В примерах обычно миксуется всё на уровне блока, а не его внутренностей.

Спасибо.