Бэм методология что это
Методология
Технологии
Библиотеки
Быстрый старт
Введение
БЭМ (Блок, Элемент, Модификатор) — компонентный подход к веб-разработке. В его основе лежит принцип разделения интерфейса на независимые блоки. Он позволяет легко и быстро разрабатывать интерфейсы любой сложности и повторно использовать существующий код, избегая «Copy-Paste».
Содержание
Блок не должен влиять на свое окружение, т. е. блоку не следует задавать внешнюю геометрию (в виде отступов, границ, влияющих на размеры) и позиционирование.
Таким образом обеспечивается независимость, при которой возможно повторное использование или перенос блоков с места на место.
Принцип работы с блоками
Вложенность
Блоки можно вкладывать друг в друга.
Допустима любая вложенность блоков.
Элемент
Составная часть блока, которая не может использоваться в отрыве от него.
Принципы работы с элементами
Вложенность
Элементы можно вкладывать друг в друга.
Допустима любая вложенность элементов.
Имя блока задает пространство имен, которое гарантирует зависимость элементов от блока ( block__elem ).
Блок может иметь вложенную структуру элементов в DOM-дереве:
Однако эта же структура блока в методологии БЭМ всегда будет представлена плоским списком элементов:
Это позволяет изменять DOM-структуру блока без внесения правок в коде каждого отдельного элемента:
Структура блока меняется, а правила для элементов и их названия остаются прежними.
Принадлежность
Элемент — всегда часть блока и не должен использоваться отдельно от него.
Необязательность
Элемент — необязательный компонент блока. Не у всех блоков должны быть элементы.
Когда создавать блок, когда — элемент?
Создавайте блок
Если фрагмент кода может использоваться повторно и не зависит от реализации других компонентов страницы.
Создавайте элемент
Если фрагмент кода не может использоваться самостоятельно, без родительской сущности (блока).
Исключение составляют элементы, реализация которых для упрощения разработки требует разделения на более мелкие части — подэлементы. В БЭМ-методологии нельзя создавать элементы элементов. В подобном случае вместо элемента необходимо создавать служебный блок.
Модификатор
Cущность, определяющая внешний вид, состояние или поведение блока либо элемента.
Имя модификатора отделяется от имени блока или элемента одним подчеркиванием ( _ ).
Типы модификаторов
Булевый
Структура полного имени модификатора соответствует схеме:
Ключ-значение
Структура полного имени модификатора соответствует схеме:
Принципы работы с модификаторами
Модификатор нельзя использовать самостоятельно
С точки зрения БЭМ-методологии модификатор не может использоваться в отрыве от модифицируемого блока или элемента. Модификатор должен изменять вид, поведение или состояние сущности, а не заменять ее.
Прием, позволяющий использовать разные БЭМ-сущности на одном DOM-узле.
совмещать поведение и стили нескольких сущностей без дублирования кода;
создавать семантически новые компоненты интерфейса на основе имеющихся.
Файловая структура
Принятый в методологии БЭМ компонентный подход применяется и к организации проектов в файловой структуре. Реализации блоков, элементов и модификаторов делятся на независимые файлы-технологии, что позволяет нам подключать их опционально.
Один блок — одна директория.
Директория блока является корневой для поддиректорий соответствующих ему элементов и модификаторов.
Такая файловая структура позволяет легко поддерживать и повторно использовать код.
Разветвленная файловая структура предполагает, что в production код будет собираться в общие файлы проекта.
Придерживаться рекомендуемой файловой структуры не обязательно. Вы можете использовать любую альтернативную структуру проекта, соответствующую принципам организации файловой структуры БЭМ, например:
Методология
Технологии
Библиотеки
Определения
Логически и функционально независимый компонент страницы, аналог компонента в Web Components. Блок инкапсулирует в себе поведение (JavaScript), шаблоны, стили (CSS) и другие технологии реализации. Независимость блоков обеспечивает возможность их повторного использования, а также удобство в разработке и поддержке проекта.
Вложенная структура
Блоки можно вкладывать в любые другие блоки.
Например, блок head может содержать логотип ( logo ), форму поиска ( search ) и блок авторизации ( auth ).
Свободное перемещение
Блоки можно перемещать в пределах одной страницы и разных проектов. Независимость блока позволяет изменять его положение на странице и обеспечивает корректную работу и внешний вид.
Так, например, логотип и форму авторизации можно поменять местами. При этом вносить изменения в CSS или JavaScript-код блоков не нужно.
Повторное использование
В интерфейсе может одновременно присутствовать несколько экземпляров одного и того же блока.
Элемент
Составная часть блока, которая не может использоваться в отрыве от него. Элементы не существуют вне блока. Каждый элемент может принадлежать только одному блоку.
Например, пункт меню вне блока меню не используется, значит является его элементом.
Модификатор
БЭМ-сущность, определяющая внешний вид, состояние и поведение блока или элемента.
Использование модификаторов опционально, количество — неограничено. Блоку или элементу нельзя одновременно присвоить разные значения модификатора.
По своей сути модификаторы похожи на атрибуты в HTML. Один и тот же блок выглядит по-разному благодаря применению модификатора.
Например, внешний вид блока меню ( menu ) может меняться в зависимости от примененного модификатора.
Модификаторы могут изменяться в процессе работы блока (например, как реакция на DOM-события блока) и по запросу из других блоков.
БЭМ-сущность
Это понятие может применяться как частное, если рассматривается отдельная БЭМ-сущность, и как собирательное для блоков, элементов и модификаторов.
Способ использования разных БЭМ-сущностей на одном DOM-узле.
совмещать поведение и стили нескольких БЭМ-сущностей без дублирования кода;
создавать семантически новые компоненты интерфейса на основе имеющихся БЭМ-сущностей.
Рассмотрим пример микса блока и элемента другого блока.
БЭМ-дерево
Представление структуры веб-страницы в терминах блоков, элементов и модификаторов. Это абстракция над DOM-деревом, которая описывает имена БЭМ-сущностей, их состояния, порядок, вложенность и вспомогательные данные.
В реальных проектах БЭМ-дерево можно выразить любым форматом, который поддерживает древовидную структуру.
Рассмотрим пример DOM-дерева:
Ему соответствует такое БЭМ-дерево:
Это же БЭМ-дерево будет иметь следующий вид в форматах XML и BEMJSON:
Реализация блока
Набор различных технологий, определяющих следующие особенности БЭМ-сущности:
дополнительные данные (например, картинки).
Технология реализации
Технология, которая используется для реализации блока.
Блоки могут быть реализованы в одной или нескольких технологиях, например:
поведение — JavaScript, CoffeeScript;
внешний вид — CSS, Stylus, Sass;
шаблоны — Pug, Handlebars, XSL, BEMHTML, BH;
документация — Markdown, Wiki, XML.
Например, если внешний вид блока задан с помощью CSS, это означает, что блок реализован в технологии CSS. А если документация к блоку написана в формате Markdown — блок реализован в технологии Markdown.
Переопределение блока
Изменение реализации блока путем добавления ему новых особенностей на другом уровне.
Уровень переопределения
Набор БЭМ-сущностей и их частичных реализаций.
Конечная реализация блока может быть разделена по разным уровням переопределения. Каждый последующий уровень добавляет или перекрывает исходную реализацию блока. Конечный результат собирается из отдельных технологий реализации блока со всех уровней переопределения последовательно в заданном порядке.
Например, в проект на отдельный уровень подключается сторонняя библиотека, которая содержит готовые реализации блоков. Проектные блоки хранятся на другом уровне переопределения.
Предположим, что необходимо изменить внешний вид одного из блоков библиотеки. Для этого не нужно менять CSS-правила блока в исходном коде библиотеки или копировать код на уровень проекта. Достаточно создать дополнительные 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 описан в документе Создаем свой проект на БЭМ.
И в заключение
БЭМ-методология — это набор правил и рекомендаций по организации работы над проектом.
В какой-то момент мы отделили методологию от ее практической реализации — платформы.
БЭМ-платформа — это частный случай реализации общих принципов БЭМ-методологии. Так как все технологии создавались с учетом требований наших проектов и развивались постепенно, БЭМ-платформа наиболее полно охватывает все возможности, которые предоставляет БЭМ-методология. Более подробно о ней можно прочитать здесь.
Все части БЭМ-платформы интегрированы для совместной работы, но могут быть использованы и по отдельности. Каждая часть решает конкретную задачу и её можно настраивать под свой процесс и заменять на другие.
Выбирайте наиболее подходящий способ для вашего проекта, экспериментируйте. Можно даже выкладывать свои проекты сайт. Мы будем благодарны вам за обратную связь.
Методология
Технологии
Библиотеки
История создания БЭМ
Типичная верстка в Яндексе 2005 года
История БЭМ началась в 2005 году. Тогда, с точки зрения интерфейса, обычный проект Яндекса был набором статических HTML-страниц, которые использовались как основа для создания шаблонов на XSL.
HTML-страницы хранились в отдельной директории, которая имела подобную структуру:
Картинки складывались в отдельную директорию. Необходимость поддержки IE 5 и отсутствие CSS3 в браузерах, вынуждало использовать картинки для реализации любого оформления, даже для закругленных уголков.
Сверстанные статические HTML-страницы нарезались в XSL-шаблоны. Если HTML изменялся, все правки было необходимо переносить вручную в XSL. И наоборот, изменения в шаблонах требовали правок в HTML (для поддержания статического HTML в актуальном состоянии).
Зарождение основ методологии
невозможно внести изменения в код одной страницы, не затрагивая код другой;
сложно подбирать названия классам.
Типичный CSS того времени содержал длинный каскад:
Совместно использовались селекторы по тегам и идентификаторам:
Верстка большого проекта была неуправляемой. Чтобы избежать этого, нужно было определить правила работы с понятиями класса, тега, визуального компонента и др.
Появление блоков
Основное время разработчиков тратилось на создание HTML-структуры страницы и написание CSS-стилей для нее. JavaScript воспринимался лишь как сопутствующая технология.
Чтобы ускорить разработку, требовалось облегчить поддержку HTML и CSS отдельных компонентов страницы. Для этого мы ввели понятие блока.
Блоком называлась часть дизайна страницы или раскладки со своим специфическим и уникальным значением, определенным семантически или визуально.
В большинстве случаев любой компонент на странице (сложный или простой) рассматривался как блок. HTML-контейнер каждого блока получал уникальный CSS-класс с тем же именем, что и у блока.
Независимый блок, может использоваться в любом месте страницы.
Контрол (независимый блок), с которым ассоциирован JavaScript-объект, обеспечивающий его функциональность. Может использоваться в любом месте страницы.
Глобальное определение, используется по необходимости. Количество сведено к минимуму.
Кроме префиксов использовались постфиксы, например:
-nojs — no javascript.
Стиль применяется в отсутствие JavaScript. Если JavaScript включен, то при загрузке страницы вызывается метод init() в onload, и постфикс удаляется из всех классов. Таким образом «включался» JavaScript для блоков.
Появление элементов
В HTML-контейнере, формирующем блок, некоторые узлы получали четкий CSS-класс. Это не только облегчило создание стилистических правил, независящих от имени тега, но и позволяло присваивать семантически значимую роль каждому узлу. Такие внутренние узлы мы назвали элементами блока, или просто элементами.
Ключевое различие между блоком и элементом в тот момент:
элемент не может существовать вне контекста родительского блока;
из блока нельзя извлечь ни один элемент.
Если элемент способен существовать вне блока, он становится блоком.
Позже стало возможным вынимать некоторые элементы из блока, сохраняя при этом рабочее состояние самого блока.
Элементы с большим количеством кода выделялись комментариями.
Унификация файловой структуры проекта
Разработчики интерфейсов обычно поддерживают несколько проектов одновременно. Работать с разными проектами легче, если все они имеют одинаковую (или очень похожую) файловую структуру. Поэтому мы унифицировали структуры репозиториев разных проектов.
Начали с того, что CSS, JavaScript и картинки стали складывать в отдельные директории.
JavaScript применялся все чаще, в проект подключались дополнительные компоненты и библиотеки.
Типичная структура верстки проекта 2006 года:
Зачатки общепортального фреймворка
При верстке нескольких проектов с похожим дизайном появлялись общие блоки.
Портал Яндекса в то время содержал больше 100 разных сервисов, выполненных в одном стиле. Для такого объема данных «Copy-Paste» из проекта в проект уже не подходил.
Первые блоки, которые вошли в Common : шапка, подвал и стили для статического текста.
Файлы блоков хранились на выделенном внутреннем сервере разработчиков ( common.cloudkill.yandex.ru в примере ниже).
Это было началом работы нашего общепортального фреймворка. Cтили из него подключались в основной проектный файл при помощи импортов непосредственно с сервера:
Возникла проблема: большое количество импортов замедляло загрузку страницы. Было принято решение прекомпилировать стили (и позже JavaScript-файлы) перед выкладкой.
Компиляция заменяет @import на содержимое внешних файлов (это называется inlining ) и оптимизирует код. Например, убирает ненужные браузеру пробелы и комментарии.
Наш внутренний инструмент для оптимизации вырос из простого Perl-скрипта в отдельный open-source-проект borschik.
Верстка независимыми блоками
К осени 2007 года правила верстки устоялись. Мы увидели практическую пользу от нового подхода, поэтому было решено рассказать об этом вне Яндекса.
На ClientSide’07 был сделан доклад про верстку независимыми блоками, которая на тот момент составляла основу наших HTML-страниц.
В докладе официально вводилось понятие блока:
Блоком будем называть фрагмент страницы, который описывается своей разметкой и стилями.
Блоки делились на простые и составные.
В простые блоки нельзя вкладывать другие блоки, в составные — можно.
Это было неверно: мы неоднократно сталкивались с тем, что даже в самые простые блоки вкладывались другие, и приходилось переделывать верстку. В итоге мы пришли к противоположному принципу:
Любой блок должен позволять вкладывать в него другой блок, когда это возможно.
Правила независимости блоков
Сформировались первые правила независимости блока:
Каждый блок имеет префикс.
В таблице стилей нет классов вне блоков.
отображать на странице один и тот же блок несколько раз;
использовать на одном DOM-узле несколько классов (что нам пригодилось в дальнейшем).
Правила полной независимости блоков
С текущей схемой оставался ряд проблем с CSS:
CSS мог работать неправильно, если в страницу включался код, написанный сторонними разработчиками (например, библиотеки).
Блоки могли неправильно отображаться из-за конфликта имен элементов.
Селекторы по тегам могли охватывать больше HTML-элементов, чем было задумано.
Поэтому мы сформулировали правила более строгой независимости блоков под названием абсолютно независимые блоки (АНБ):
Не писать селекторы по тегам. Стили блоков и элементов описывать через селекторы классов.
Всем классам внутри блока давать имена, начинающиеся с имени этого блока.
Мы понимали, что наличие класса у каждого DOM-узла существенно увеличивает объем HTML-кода. На тот момент мы считали, что это дорого, и применяли такой подход в исключительных случаях.
Первые правила именования — префиксы
Так как распространенной проблемой в программировании является подбор имен, мы решили задавать имена блоков с помощью разных префиксов с разной семантикой:
h- — обертки для нескольких блоков;
g- — глобальные стили.
Появление модификации блоков
Работая с блоками, мы поняли, что они могут иметь разные состояния.
Например, «Кнопка» (блок button ) может быть:
Вместо того, чтобы создавать три разных блока, мы начали делать модификации.
Модификацию мы определили как особое состояние блока или как метку, несущую определенное свойство блоку.
Возможные варианты модификации:
Блок может изменить свой внешний вид в зависимости от того, где он находится. Это модификация от контекста.
Можно добавить блоку второй класс. Это модификация постфиксом, она не зависит от контекста.
Общепортальный фреймворк — Лего
Весной 2008 года была поставлена задача создать брендбук, описывающий наш портальный стиль. Решили начать работу с написания HTML/CSS кода.
Структура репозитория
На верхнем уровне репозиторий разделен по технологиям:
Директория каждой технологии имеет свою структуру.
CSS распределяется на следующие директории:
block — общепортальные блоки;
util — блоки, которые имеют смысл вне Яндекса, их можно выложить в open source;
service — стили для конкретных сервисов Яндекса. Подключив их к сервису, можно отобразить шапку или подвал.
Структура директории HTML аналогична CSS:
JS находится в зачаточном состоянии и складывается в одну директорию:
У каждого сервиса есть XML-файл, использующийся для построения шапки:
XSL блоков находится в одной директории. Каждому блоку соответствует один файл:
Лего подключается в проекты с помощью svn:externals.
При финальной сборке проекта код библиотеки полностью включается в проект, что можно сравнить со статической линковкой.
Такой подход позволяет выпускать версии сервисов с разными версиями Лего и переходить на новую версию тогда, когда это удобно команде проекта.
CSS-файлы
CSS-файлы, подключавшиеся на страницах, состояли из @import ‘ов реализации блоков.
Эти @import ‘ы писались вручную.
Правила именования
Общепортальный фреймворк — Лего 1.2 (2008)
Структура репозитория
В рамках версии Лего 1.2, был произведен рефакторинг, и структура репозитория проекта изменилась.
От идеи выноса кода в open source на тот момент отказались и вернулись к ней только через два года.
Правила именования
Для модификации постфиксом вместо дефиса начали использовать подчеркивание. Это позволило визуально отделить имя блока от имени модификатора, что позже пригодилось при реализации инструментов, упрощающих работу с кодом.
Лего 2.0. Появление БЭМ
В марте 2009 года вышла версия Лего 2.0.
БЭМ — аббревиатура от Блок, Элемент, Модификатор. Это три ключевые сущности, которые мы используем при разработке компонентов интерфейса.
Что же принципиально изменилось с выходом версии 2.0?
Основное изменение — мы вывели вперед блоки, а не технологии. Отныне блоки первичны, а технологии их реализации — вторичны.
Независимый блок
Может быть использован в любом месте страницы.
В XML блок представлен тегом в пространстве имен lego :
HTML-класс блока соответствует имени этого тега:
CSS-правила пишутся на класс:
Элемент
Составная часть блока, которая не может использоваться в отрыве от него.
В XML элемент представлен в пространстве имен lego без префикса:
Класс в HTML соответствует имени этого элемента без префикса.
CSS-правила пишутся на класс:
Файлы элемента хранятся в отдельной директории.
Имена файлов элементов пишутся через точку: b-head-logo.name.css
Модификатор
Определяет внешний вид, состояние и реже поведение блока.
В XML модификатор представлен атрибутом в пространстве имен lego :
В HTML используется дополнительный класс:
CSS-правила пишутся на класс:
Файлы для модификатора находятся в отдельной директории. Имя директории модификатора начинается с подчеркивания:
Декларация используемых блоков
Все компоненты Лего описываются в XML-файле.
Из него генерируются CSS-файлы.
На примере этого файла видно, что сначала указывается общий код, а потом добавляются стили, чтобы привести Лего-блоки к дизайну проекта.
Из XML-декларации генерируются и JS-файлы.
Мы перестали писать эти файлы руками, началась генерация кода.
Скорость селекторов (2009)
При реализации новой версии Яндекс.Почты была поставлена задача сделать ее быстрой.
Для решения задачи мы начали использовать XSL в браузере (и подгружать XML, необходимый для отрисовки данных на странице). Возникла проблема: трансформации отрабатывались быстро, но вставка в DOM полученного результата происходила очень медленно. При этом, отключение CSS решало проблему.
Выяснилось, что работу замедляют CSS-селекторы, которые при большом DOM-дереве и большой таблице стилей оказывают существенное влияние на скорость отрисовки браузером страницы.
Результаты исследования подробно описаны в статье.
Решение проблемы было уже готово — это абсолютно независимые блоки (АНБ).
В классы элементов вносится имя блока, селекторы получаются простыми и быстрыми.
Стабилизация нотации
Постепенно мы пришли к тому, что нотация в коде и файловая структура устоялись и уже не меняются.
Теперь они совпадают с CSS-селекторами.
Были реализованы модификаторы у элементов по аналогии с модификаторами блоков:
В имя файла модификатора и в его класс внесен тип модификатора.
Причина этого изменения — работа с модификаторами из JavaScript.
БЭМ и open source (2010)
В 2010 году мы снова вернулись к идее open source. Мы создали организацию bem на GitHub.
Библиотека bem-bl
Мы начали выносить блоки из Лего в bem-bl, проводя одновременно с этим рефакторинг.
Параллельно с переносом блоков в новую библиотеку публиковали информацию про них.
Инструменты
Для работы с файлами по БЭМ-методам нам понадобились свои инструменты. Началась реализация инструментов bem-tools на JavaScript под Node.js.
Уровни переопределения
Возникло новое понятие — уровень переопределения. Так мы стали называть директории с реализацией блоков.
Например, в проекте может быть:
Публичная библиотека блоков с GitHub;
Внутренняя библиотека lego;
Блоки самого проекта.
На уровне переопределения можно задать другую схему именования директорий/файлов, отличную от нашей. Для этого нужно указать новый уровень в конфигурации:
Например, вы можете задать другие разделители между именем блока и элемента, или не раскладывать все по директориям, а использовать плоскую структуру файлов.
Шаблонизатор BEMHTML
После экспериментов с разными шаблонизаторами, был разработан шаблонизатор BEMHTML, который позволяет:
Писать шаблоны в БЭМ-терминах.
Исполнять эти шаблоны как на сервере, так и в браузере, поскольку шаблоны компилируются в простой и быстрый JavaScript.
Резюме
Появлению БЭМ в том виде, что мы имеем сейчас, предшествовал долгий период проб и экспериментов.
Хочется обратить ваше внимание, что на всех этапах своего развития это всё же был БЭМ.
Тот БЭМ, что мы используем сейчас, — не единственное верное решение.
Мы рекомендуем использовать БЭМ в ваших проектах в том объеме, в котором он принесет наибольшую пользу. Можно пробовать применять его только для верстки. Мы сами начинали именно с этого. Гибкость БЭМ-методологии позволяет настраивать ее под свои текущие процессы и организовывать работу над проектом.
Главное понять, какие плюсы БЭМ принесет в ваш проект, выбрать подходящую для вас схему и начать применять у себя!
Если у вас возникнут вопросы, обязательно задавайте их на нашем форуме.