Бэм css что это

БЭМ-методология: с чего всё начиналось и зачем это всё нужно

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

Конечно, все началось с собственных потребностей Яндекса. Вместе с тем, как он рос, росло и количество сотрудников, которые занимаются фронтендом. Постепенно команда увеличилась настолько, что стало очевидно — без единых стандартов работать будет сложно. К тому же, мы находимся в офисах Яндекса в разных городах. Возникла идея создать общую методологию, которая поможет организовать процессы в большой команде, работающей над разными проектами. А главное то, что мы хотели не только упорядочить и ускорить разработку, но и снизить порог входа в проект для нового разработчика.

Для чего нужна БЭМ-методология

Мы стремились к тому, чтобы с увеличением числа разработчиков улучшалось и качество продукта. Это значит, что разработчики должны быть в курсе работы друг друга и не изобретать заново то, что уже реализовано. Мы хотели создать единую команду, которая работает над разными проектами.

История развития БЭМ

Как верстали 10 лет назад

В 2005 году обычный, с точки зрения интерфейса, проект был набором статических HTML-страниц. Вот такой была типичная структура проекта того времени:

Типичный CSS того времени в большинстве случаев содержал длинный каскад.

Малейшие изменения требовали длительного рефакторинга. Свёрстанные статические HTML-страницы нарезались в шаблоны. Если HTML изменялся, все правки было необходимо переносить вручную в шаблон.

Вёрстка в больших проектах была неуправляемой.

Основы БЭМ-методологии

Технологии (HTML, CSS, JavaScript), которые мы использовали, изменялись в зависимости от требований проекта, а принципы БЭМ должны были быть универсальны.

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

Чтобы ускорить разработку, необходимо было облегчить поддержку HTML и CSS отдельных компонентов страницы, сделать код менее связанным. Для этого мы разбили страницу на части. Так появилось новое понятие — блок. Блок мог состоять из различных элементов, которые не использовались вне самого блока. Состояния и поведение блока и элемента можно было задавать с помощью модификатора.

Это были три ключевых понятия, на которых основывалось большинство правил. Аббревиатура от трех слов Блок, Элемент и Модификатор стала названием методологии — БЭМ.

Логически и функционально независимый компонент страницы. Блок полностью самодостаточен: у него может быть свое поведение, шаблоны, стили, документация и не только. Блоки могут использоваться в любом месте страницы, повторно, даже в другом проекте.

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

Элемент

Часть блока, которая не может использоваться в отрыве от него и имеет смысл только в рамках своего родителя. Элементы могут быть обязательными и опциональными.

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

Модификатор

Свойство блока или элемента, которое меняет их внешний вид, состояние или поведение.
Модификатор имеет имя и может иметь значение. Использование модификаторов опционально. У блока/элемента может быть несколько разных модификаторов одновременно.

Так, например, с помощью модификатора можно изменить не только цвет меча, но и его функциональность (как показано в случае с красным мечом):

Правила именования CSS-селекторов

Все принципы БЭМ формировались и внедрялись постепенно. Мы начали с того, что сформулировали жесткие правила именования CSS-селекторов.

Правила формирования имени БЭМ-сущности

Мы долго экспериментировали с префиксами в именах, но в итоге отказались от них.

Существует ряд альтернативных схем именования. Выбор всегда остается за вами.

Но мы рекомендуем придерживаться описанной выше схемы, так как инструменты БЭМ-платформы умеют работать именно с данным вариантом именования.

БЭМ в HTML

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

В HTML каждая БЭМ-сущность определяется своим классом.

В простейшем случае блок соответствует DOM-узлу, один к одному. Но DOM-узел и блок — это не всегда одно и то же. На одном DOM-узле может совмещаться несколько сущностей. Это называется миксом.

Организация файловой системы

Нас не устраивала первоначальная структура проекта в файловой системе: в ней было сложно ориентироваться и находить нужные технологии сущностей.

Сначала мы попробовали разделить репозиторий проекта по технологиям:

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

Блоки первичны, технологии — вторичны

Чтобы создать нужную нам структуру проекта и реализовать наши цели, которые мы перед собой ставили, мы вывели на передний план блоки, а не технологии.

Блок в файловой системе полностью независим: все технологии, необходимые для его реализации, находятся в директории этого блока.

Чего мы добились:

Технологии реализации

Придумали новый термин — технология реализации.

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

Выбор технологий реализации не ограничен, разве только требованиями вашего проекта.

В новой организации файловой структуры каждая технология реализации представляет собой отдельный файл с соответствующим расширением. Все файлы реализации блока хранятся в директории этого блока.

Всё в проекте перестраивается относительно этого нового принципа. Блок становится ключевым понятием БЭМ. Соответственно, изменяется и структура файловой системы.

Правила организации файловой системы БЭМ-проекта

Уровень переопределения

Уровнем переопределения мы стали называть директории с реализацией блоков. Появление уровней позволило изменять реализацию блока, добавляя новые свойства (доопределять) или изменяя старые (переопределять) на другом уровне. Конечная реализация блока собирается со всех уровней последовательно.

Если сравнить уровни со слоями, то базовый слой – это исходная реализация блока, а каждый последующий слой накладывается сверху и дополняет (наследует) или изменяет базовую реализацию.

Как начать работать с БЭМ

Как вы могли заметить, наша команда тоже начинала работу с БЭМ постепенно. Гибкость БЭМ-методологии позволяет настраивать её под ваши текущие процессы.

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

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

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

БЭМ и технологии

В веб-разработке финальный продукт состоит из разных технологий (например, HTML, CSS, JavaScript). Основной принцип БЭМ-методологии — использовать единые термины и подходы к реализации во всех применяемых технологиях.

JavaScript

Чтобы работать в БЭМ-терминах и писать декларативно JavaScript, который можно разделять по уровням переопределения, нам понадобился собственный фреймворк — i-bem.

БЭМ-дерево

Типичная веб-разработка сводилась к тому, что мы писали HTML, затем нарезали его на шаблоны. При изменении дизайна приходилось менять HTML и шаблоны вручную.
Чтобы избавиться от ручной работы, мы добавили новый уровень абстракции — БЭМ-дерево, которое позволяет работать со структурой веб-страницы в терминах блоков, элементов и модификаторов. БЭМ-дерево — это абстракция над DOM-деревом.

БЭМ-дерево описывает все БЭМ-сущности, которые используются на странице, их состояния, порядок, вложенность. Оно может быть выражено любым форматом, который поддерживает древовидную структуру, например, XML или JSON.

Рассмотрим пример DOM-дерева:

Ему соответствует такое БЭМ-дерево:

Его можно сравнить с шаблонизатором Jade, но отличие в том, что мы пишем не HTML, а используем абстракции.

Это же БЭМ-дерево будет иметь следующий вид в форматах XML и BEMJSON:

BEMJSON — JavaScript-формат, который позволяет работать в БЭМ-терминах. BEMJSON позволяет абстрагироваться от HTML-разметки и описывать страницу в терминах блоков, элементов и модификаторов.

Мы описываем страницу, которую хотим получить в браузере в виде БЭМ-дерева и не пишем HTML руками: шаблонизатор BEMHTML обрабатывает BEMJSON и генерируют HTML.

БЭМ и инструменты

Чтобы работать со всеми технологиями в удобном для разработчика виде, мы разделили проект на множество отдельных файлов. Это дало нам описанные выше преимущества. Но нам понадобилась сборка и оптимизация, чтобы созданный код мог работать в браузере.

Собирать все файлы вручную неудобно, мы начинаем автоматизировать большинство повторяющихся процессов. Появляются bem-tools — набор инструментов для работы с файлами по БЭМ-методологии. Позже на смену bem-tools пришел ENB.

Чтобы иметь возможность собрать разрозненные файлы, ничего не знающие друг о друге, используется технология DEPS, которая указывает зависимости одного блока от другого или от набора блоков.

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

БЭМ и библиотеки

Многие БЭМ-библиотеки можно найти в open source. Базовыми являются:

Такой способ поставки называется Dist и включает предсобранный CSS- и JavaScript-код и шаблоны. С ним вам не потребуется инструменты для сборки или шаблонизаторы — блоки заранее собраны и работают.

О том, как подключать файлы с CDN или локально, использовать bower или самостоятельно собрать файлы библиотеки из исходников, читайте в описании библиотеки.

Заготовка проекта

Быстро начать разработку БЭМ-проекта можно с помощью project-stub — проекта с заранее предустановленными технологиями и инструментами. Начинать знакомство с ним стоит с помощью быстрого старта по БЭМ.

Расширенный пример использования project-stub описан в документе Создаем свой проект на БЭМ.

И в заключение

БЭМ-методология — это набор правил и рекомендаций по организации работы над проектом.

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

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

Выбирайте наиболее подходящий способ для вашего проекта, экспериментируйте. Можно даже выкладывать свои проекты сайт. Мы будем благодарны вам за обратную связь.

Источник

БЭМ для начинающих. Очевидные и неочевидные вопросы верстки

Jan 18, 2018 · 15 min read

Эта статья написана по мотивам БЭМапа — митапа по БЭМ — с одноименным названием БЭМ для начинающих.

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

На БЭМапе Владимир Гриненко дал ответы на эти вопросы. Мы решили сохранить их в статье.

Немного теории и практики:

Зачем вам БЭМ

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

Основные почему

Не используем идентификаторы (ID селекторы)

ID определяет уникальное имя HTML-элемента. Если имя уникально, второй раз в интерфейсе его использовать не получится. Это мешает повторно использовать код.

1. ID обязателен для работы с JavaScript.

На практике современным браузерам не важно, с какими данными работать: ID или классами. Браузер одинаково быстро обрабатывает любой селектор.

Не используем селекторы тега

HTML-разметка страниц нестабильна: новый дизайн сайта может поменять вложенность разделов, уровень заголовоков (например, с

) или превратить абзац

Даже если дизайн не меняется, набор тегов ограничен. Чтобы использовать существующую верстку в другом проекте, придется решать конфликты стилей, написанных на одни и те же теги.

Расширенный набор семантических тегов также не может выразить все потребности верстки.

Например: в шапке страницы расположен логотип, по клику на который открывается главная страница сайта ( index ).

Чтобы отличать ссылку с логотипа от обычной ссылки в тексте, понадобятся дополнительные стили. Отменим подчеркивание и синий цвет для ссылки в логотипе:

Для тега отменять подчеркивание и синий цвет не нужно. Поэтому вынесем общие правила для ссылки в логотипе с разных страниц:

На первый взгляд, такой код имеет право на существование. Но представьте ситуацию, в которой дизайнер убирает логотип из макета. Такие имена селекторов не помогут понять, какие стили удалять из проекта вместе с логотипом. Селектор header a не показывает связь ссылки и логотипа. Такой селектор может принадлежать ссылке в меню шапки или, например, ссылке на профиль автора, а селектор header span может относиться вообще к любой части шапки.

Чтобы избежать путаницы, достаточно записать стили для логотипа с помощью селектора класса с именем logo :

Не используем общий сброс стилей (reset)

Общий сброс стилей — это глобальные CSS-правила, созданные для всей страницы. Они оказывают влияние на все узлы верстки, нарушают независимость компонентов и затрудняют их повторное использование.

В БЭМ не принято использовать «reset» и «normalize» даже для отдельно взятого блока.

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

Не используем универсальный селектор (*)

Универсальный селектор сообщает, что в проекте создан стиль, который влияет на все узлы в верстке. Это накладывает ограничения на повторное использование верстки в другом проекте:

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

Общие стили не выигрывают время: часто разработчик начинает с того, что сбрасывает все отступы для универсальных компонентов ( * < margin: 0; padding: 0; >), а потом все равно задает их как в макете (например, margin: 12px; padding: 30px; ).

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

Вложенные селекторы увеличивают связность кода и затрудняют его повторное использование.

БЭМ не запрещает вложенные селекторы, но рекомендует не злоупотреблять ими.

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

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

Комбинированные селекторы имеют более высокую специфичность, чем одиночные, поэтому переопределять блоки становится сложнее.

Рассмотрим такой код:

Теперь добавим блоку модификатор active :

Если использовать простые селекторы классов, переопределение стилей не вызовет проблем:

Не совмещаем тег и класс в селекторе

Совмещение тега и класса (например, button.button ) повышает специфичность CSS-правил и затрудняет их переопределение.

Рассмотрим такой код:

И добавим блоку модификатор active :

Методология в редких случаях допускает объединение селекторов тега и класса, например, для стилизации комментариев в CMS-системах, которые не позволяют генерировать правильную разметку.

В комментарии пользователь может написать любой текст, вставить картинки или добавить свою разметку. Чтобы оставаться в рамках дизайна сайта, разработчик может заранее определить стили всех тегов, которые доступны пользователю, и применять их каскадом к вложенным блокам:

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

Селекторы атрибутов по информативности уступают селекторам классов. Чтобы доказать это, рассмотрим пример с формой поиска в шапке:

Воспользуемся селекторами атрибутов, чтобы записать стили для формы:

В таком примере по именам селекторов невозможно однозначно определить, что стили относятся к форме поиска. Нагляднее записать классами. В классах нет ограничений, чтобы писать понятно.

Можно записать, например, так:

Код стал более однозначным: теперь понятно, что стили относятся к форме, которая отвечает за поиск.

Но вложенность селекторов по-прежнему повышает специфичность CSS-правил и мешает безболезненно переносить верстку из проекта в проект. Чтобы избавиться от вложенности, воспользуемся принципами БЭМ.

Короткие выводы

Классы — единственный селектор, который позволяет изолировать стили каждого компонента в проекте, повысить читаемость кода и не ограничивать повторное использование верстки.

БЭМ. От теории к практике

Основы БЭМ

Методология БЭМ — это набор универсальных правил, которые можно применять независимо от используемых технологий, будь то CSS, Sass, HTML, JavaScript или React.

БЭМ помогает решить следующие задачи:

В БЭМ-проекте любой интерфейс делится на блоки, которые могут содержать элементы. Блоки — это независимые компоненты страницы. Элементы не существуют вне блока. Каждый элемент может принадлежать только одному блоку.

Именно блокам и элементам посвящены первые две буквы в аббревиатуре БЭМ.

Имя блока всегда уникально. Оно задает пространство имен для элементов и устанавливает видимую связь между всеми составляющими блока. Длинные, но понятные имена блоков и элементов позволяют определить связь между компонентами и не потерять составные части этих компонентов при переносе верстки.

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

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

Запись имен в классах с помощью блоков и элементов решает еще одну важную проблему: избавляет от вложенности селекторов. У всех селекторов в БЭМ-проекте одинаковый вес. То есть переопределять стили, написанные по БЭМ, гораздо удобнее.

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

Суть именования компонентов в БЭМ в том, что в имени можно явно указать связь блока и его элементов.

Третья буква в аббревиатуре БЭМ

Официально буква «М» означает «модификатор», но негласно под нее попадает еще одно очень важное понятие в БЭМ — «микс». И модификаторы и миксы изменяют блок и его элементы. Давайте рассмотрим подробнее.

Модификатор определяет внешний вид, состояние и поведение блока либо элемента.

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

Разберемся, как работают модификаторы.

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

В БЭМ можно добавить блоку новые стили с помощью модификатора:

Форма может быть уникальна по разным показателям — цвету, размеру, типу, теме оформления. Все эти параметры можно задать с помощью модификатора:

Одна и та же форма может выглядеть по-разному и при этом быть одного размера:

При этом селекторы для каждого модификатора все равно будут иметь одинаковый вес:

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

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

Модификатор позволяет получать очень частные случаи использования универсальных компонентов. При этом код блока или элемента не меняется, на DOM-узле просто создается нужная комбинация из модификаторов.

Микс позволяет одинаково форматировать разные HTML-элементы, совмещать поведение и стили нескольких сущностей без дублирования кода и решать задачи абстрактных блоков-оберток.

Миксом называется одновременное размещение нескольких БЭМ-сущностей (блоков, элементов, модификаторов) на одном DOM-узле.

Миксы, как и модификаторы, используются, чтобы изменять блоки. Разберем примеры, когда нужно применять миксы.

Можно вынести общие стили для таких блоков, но повторно использовать такой код не получится.

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

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

1. Создать модификатор для пункта меню, который превратит пункт в ссылку:

2. Воспользоваться миксом универсального блока link и элемента item блока menu :

Внешняя геометрия и позиционирование. Отказываемся от абстрактных HTML-оберток

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

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

Рассмотрим на примере универсального блока меню, который нужно разместить в шапке. В верстке блок меню должен отступать от родительского блока на 20px.

Существует несколько решений для этой задачи:

1. Написать стили с отступами самому блоку меню:

В таком случае блок menu перестанет быть универсальным. Если понадобится разместить меню в подвале страницы, придется править стили, потому что отступы скорее всего будут другими.

2. Создать модификатор для блока меню:

В таком случае в проекте появятся два типа меню, хотя это не так. Меню остается одно и то же.

3. Определить внешнее позиционирование блока — вложить блок menu в абстрактную обертку (например, блок wrap ), где задать все отступы:

Чтобы окончательно отказаться от соблазна создавать модификаторы и менять стили самого блока для позиционирования его на странице, нужно понять простую вещь:

Отступ от родительского блока — это не свойство вложенного блока быть с таким отступом. Это свойство родительского блока — знать, что вложенный в него блок должен отступать от границы на определенное количество пикселей.

4. Использовать микс. Знания про позиционирование вложенных блоков описываются в элементах родительского блока. Затем элемент родительского блока миксуется к вложенному блоку. В таком случае вложенный блок не специфицирует никакие отступы и может быть легко переиспользован в любом месте.

Продолжим рассматривать пример:

Элемент родительского блока (в нашем случае это header__menu ) полностью решает задачу абстрактных блоков-оберток, отвечающих за внешнее позиционирование блока.

Удобство параллельной разработки

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

В качестве примера рассмотрим библиотеку блоков bem-components, которая содержит универсальные блоки, такие как ссылка, кнопка, поле ввода. Из универсальных компонентов легко создавать более сложные блоки. Например, селект или чекбокс.

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

Блоки в файловой структуре

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

Реализация каждого блока хранится в отдельной папке проекта. Каждой технологии (CSS, JavaScript, тестам, шаблонам, документации, картинкам) соответствует отдельный файл.

Код модификаторов и элементов также хранится в отдельных файлах блока. Такой подход позволяет подключать только те модификаторы и элементы, которые необходимы для данной реализации блока.

Чтобы улучшить навигацию в проекте, модификаторы блока со множественными значениями также можно объединять в отдельные директории.

Файловая структура любого БЭМ-проекта состоит из уровней переопределения. Уровни переопределения позволяют:

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

Шаблонизация в БЭМ

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

В БЭМ используется шаблонизатор bem-xjst, который содержит два движка:

Если шаблоны к блокам не написаны, шаблонизатор по умолчанию установит блокам тег

Сравните декларацию блоков и выходной результат HTML:

1. Меняем тег блока menu :

По аналогии с CSS, шаблон будет применен ко всем блокам menu на странице.

Шаблоны в БЭМ написаны на JavaScript, поэтому добавить новый элемент в шаблон также можно с помощью JavaScript:

3. Изменяем теги всем элементам inner и item :

5. Изменяем существующий шаблон. Правила в шаблонах применяются так же, как в CSS: нижнее правило перекрывает верхнее. Добавим новые правила в шаблон, изменим тег ссылкам с на :

Тестирование верстки

Протестировать работу всей страницы проблематично. Особенно в динамическом проекте, который связан с базой данных.

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

Сборка проекта

Сборка решает следующие задачи:

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

С чего начать?

Разработчики БЭМ создали шаблонный проект project-stub, в который по умолчанию подключены технологии и библиотеки БЭМ. Он содержит необходимый минимум конфигурационных файлов и директорий, чтобы быстро развернуть проект с нуля.

Источник