С чего начинается БЭМ?

    БЭМ расшифровывается как «Блок Элемент Модификатор». Это подход к web-разработке, позволяющий быстро создавать сайты с гибкой архитектурой. Он знаком многим, кто занимается HTML/CSS вёрсткой.

    Изобретённый в Яндексе, БЭМ постепенно проникает и в разработку других компаний.
    В данный момент основные мейнтейнеры работают над выводом в Open Source фреймворка, построенного по методологии БЭМ, инструментов и многих полезных утилит.


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

    Но теперь опубликована каноническая статья «Что такое БЭМ?», позволяющая изучить его с самых основ.

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

    • Типовые сайты нужно разрабатывать быстро;
    • Проект должен жить долго (годы) и легко поддерживаться;
    • Нужно уметь легко масштабировать команду. На проекте может работать один человек, а может десять;
    • Внутри команды должны быть чёткие зоны ответственности;
    • Код нужно использовать повторно.


    Вместе с развитием методологии и её «обкаткой» оказалось, что она подходит не только для больших порталов, но и для web-студий, и других моделей разработки.

    Для применения методологии мейнтейнерами разрабатываются технические решения, не просто удовлетворяющие БЭМ, а имеющие отдельные преимущества. Это, например, «особенный» JavaScript. И JavaScript-based шаблонизатор. И набор инструментов, реализованных на NodeJS.
    Поделиться публикацией
    Комментарии 61
      +14
      Так с чего же, все таки, начинается БЭМ?
        +4
        В статье была неверная ссылка, извините.
          +2
          С «Б».
          +1
          Спасибо! Скажите, я правильно понимаю что вся идея (и соглашения об именовании) БЭМ исходит из того что в IE6 не поддерживается CSS-конструкция ">" (непосредственный потомок)?
            +2
            Из-за этого в том числе, но не только. «Полные» имена для CSS-классов нужны, чтобы уменьшить контекстную зависимость. Тогда блоки можно будет, не боясь, вставить в другие блоки.

            А что касается >, то элементы могут быть не только непосредственными потомками. Их можно как угодно вкладывать друг в друга.
              +2
              Прежде всего, идея основана на том, что IE6 не поддерживает множественные классы, поэтому появляются вот такие грабли: class="menu__item menu__item_state_current" вместо нормальной цепочки: class="menu__item state_current", которую потом можно записать как: .menu__item.state_current { … } …для нормальных браузеров.

              Ну и селектор потомка, да.
                +3
                Здесь опять же, не только IE6, но и контектсная зависимость.
                Иногда всё-таки нужно использовать каскад и изменять элемент, если у блока (его родителя) есть определённый модификатор. В случае, когда модификатор не содержит имени блока, к которому относится, он может подействовать не только на элементы этого блока, но и на элементы вложенных блоков.
                  +1
                  Вопрос другой: зачем дублировать префикс родителя (тем самым, создавая потенциально менее гибкие элементы конструктора) вместо того, чтобы писать всё цепочками?

                  При условии отказа от IE6, конечно же.
                    +9
                    не совсем, дублирование родительского блока нужно и для того
                    — чтобы не пересеклись имена элементов, иначе все равно везде прийдется писать каскад от блока типа .block elem.elemmod что тоже не очень удобно
                    — чтобы работая со сгенерированным кодом (в любом вебинспекторе) было сразу понятно к какому блоку относится элемент и модификатор
                    — в случае когда происходят миксы эелментов к блоку и наоборот, и элементов одного блока к элементам другого — без дублирования названия блока будет ад

                    основная мысль: БЭМ это не только css — он на всех уровнях технологий. Поэтому вариант при котором будут потенциальные пересечения именования нужно исключить на корню.
                      +1
                      .block elem.elemmod --> .block .elem.elemmod
                        +2
                        И еще:
                        селектор .b-block_modifikator сработает по определению быстрее чем двойной .b-block.modifikator
                        0
                        Например, вот за этим
                        <div class="b-block1 b-block1_mod_val b-block2 b-block2_mod_val"

                        Кроме того, из JS находить b-block1_mod_val быстрее, чем b-block1.mod_val
                          0
                          А вот такой сложный вопрос: если бы с самого начала не было IE6, был ли БЭМ концептуально таким же?
                            0
                            Да, как минимум причина «в IDE не видно по названию файла, к какому блоку относится модификатор» была бы неизменна. С точки зрения технологи — как только дошли до модификации JS, уже возникли бы проблемы, решение которых подвело бы к тому, что мы имеем сейчас.
                            Или вот возможность выносить элемент за пределы блока в DOM-структуре тоже «концептулаьно» появилась не сразу. А она нужна, например чтобы для b-form-checkbox (как-нибудь зарелизим) размещать b-form-checkbox__label где угодно.
                              0
                              Да. Что интересно, практически каждое архитектурное решение обусловлено более чем одной причиной. Это позволяет надеяться, что мы нащупали некие «глубинные принципы» к которым сходятся задачи/проблемы из разных областей.
                          +1
                          Пробовал как-то знакомиться с бемом, скажем если мы пишем яндекс то да, технология оправдывает себя, если мы пишем что-то где меньше 100 шаблонов т оя бы все же не стал использовать бем в чистом виде, ибо грамотные цепочки позволили бы ускорить процесс.

                          ну и про IE6 забыли давно уже ) пора юзерам с этим браузерам таки увидеть печальную картину с неработающем сайтом.
                            +1
                            Мне тоже кажется что на небольших проектах БЭМ будет скорее тормозить процесс, нежели ускорять его. Так как нужно выполнять большое количество лишних действий, сборка, описание структуры страницы, создание всей этой мега-разветвленной системы папок и т. д.
                              +4
                              это верно в следующих случаях:
                              — если вы только начинаете работать с БЭМ и у вас нет наработанных блоков
                              — если вы работаете над проектом класса: «сделал и забыл»
                                +3
                                Что-то вы не о том, чем мне помогут блоки наработанные? если для каждого сайта свой layout свой css которые не перекочевывают от сайта к сайту. Придется каждый раз с нуля писать эти блоки и тд и тп.

                                Давайте взглянем почему ребята из яндекса писают кипятком от слова БЭМ? ))
                                Все начиналось с того что был сайт яндекса, жил себе потихоньку, жил и разростался, компания начинала осваивать новые области, появились новости, маркет и ещё огромное количество подразделов, в свою очередь скажем поиском яндекса занимается одна команда (к примеру в Москве), а вот яндекс-маркетом другая где-нибудь в Питиере. А сайт один и стилистика сайта должна быть одна, а тут кто-то решил чуть поменять меню и все у дргих съехало ну или же пришлось бы каждый сайт верстать с нуля в общем стиле.

                                Пришел БЭМ и теперь каждая команда разработчиков имеет набор блоков которые уже реализую какую-то часть интерфейса в стиле сайта и которые НЕЗАВИСИМЫ!!! то есть теперь каждая команда берет нужный блок вставляте куда надо и вуаля все отрисовалось, а если надо чтобы список был горизонтальный скажем а не вертикальный, добавляем модификатор и опа мы ничего не сломали.

                                Я сам использовал бэм на одном из проектов, был крупный сайт — торговая площадка ) Тогда прада ещё БЭМ инструментов не было и писали для сборки. Но в общем подход оправдал себя! Но в итоге набралось огромное количество этих блоков так как сайт был очень бтольшой.

                                Теперь же стандартный сайт: новости, каталог, гостевая, галерея, статические страницы это не для БЭМ здесь хорошо бы использовать цепочки в css .sidebar-left .menu {} .sidebar-right .menu {} вот это тут реально время сэкономит и поможет поддерживать так как:
                                1) над сайтом работает одна комагда (пусть там и 4-5 человек не суть, но одна и вместе)
                                2) в сайте нет 100 шаблонов в которых можно запутаться и упустить скрытые зависимости

                                  0
                                  Для небольшого статического сайта в принципе все равно, каким подходом руководствоваться. Потому, что ключевое слово здесь — «небольшой». Небольшие нагрузки, небольшое количество страниц и, собственно, блоков.
                                    +2
                                    Что-то вы не о том, чем мне помогут блоки наработанные?

                                    Возьму из вашего же примера — блок новостей.
                                    В 90% случаях блок новости от сайта к сайту не сильно меняется.
                                    Сделав такой блок один раз и предусмотрев его расширяемость, можно с чистой совестью реиспользовать его для других проектов. Да, часть CSS (отступы, размеры и цвета) придется переопределять, но это не соизмеримо с разработкой блока с нуля.
                                    Более того, подобные блоки умеют накапливать ваш опыт, если в очередном проекте всплывет ошибка, вы ее исправите и она уже не появится на следующем или добавится новая функциональность, которая сделает блок только лучше, и которую вы сможете «бесплатно» использовать в следующем проекте.
                                    Я не вижу причин каждый раз писать заново блок новостей. Для меня их нет. И мне, кажется, что вы не начинаете проект с пустой папки. Наверняка у вас есть скелет проекта, который и используется в качестве отправной точки, например html болванка, css reset, jquery и пр.

                                    Что касается .sidebar-left .menu {} .sidebar-right .menu {}, завтра клиент захочет добавить в sidebar-left еще 2 блока like .menu, но «немного» другие — появится .sidebar-left .menu-new {} .sidebar-left .menu-new-2 {}.

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

                                    Более того побочным эффектом БЭМ подхода является его документированность. Если использовать рекомендованную структуру, то только по имени элемента конкретного блока можно определить точное местоположение файла, который надо редактировать. Время входа в такой проект несоизмеримо меньше чем в проект вида .sidebar-left .menu {}.

                                    А популярность всяких blueprint, html5-boilerplate и и прочих CSS заготовок-фреймворков говорит о том, что люди готовы реиспользовать код, БЭМ — один из способов это делать.
                                      0
                                      мне кажется blueprint и html5-boilerplate — разные вещи, первый — это фреймворк для верстки, второй это голая основа.

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

                                      Мое мнение: есть большие интернет порталы — для которых бем спасение, есть обычные сайты для который он вреден. И я это проверил на своем опыте реализуя и то и то разными способами.
                                        +3
                                        Покажите, пожалуйста, 5 своих сайтов в которых сильно отличается блок новостей.
                                  +6
                                  Вы правы, это требует определённой воли, даже если подход оправдывает себя.
                                  Мы в свою очередь постоянно боремся над упрощением и отказом от рутинных операций. В частности, файлы руками никто не создаёт, для этого есть БЭМ инструменты, заботящиеся о правильном нэйминге и даже предоставляющие дефолтный контент.
                                  Сборка осуществляется не прямым набором команд, а при помощи GNUmakefile, реализованного с учётом нужд проекта. Это сводит сборку к запуску одной команды.
                                  Что не набирать даже эту команду, мы пользуемся утилитой Monkey Joe. Она отслеживает изменения файлов по нотификациям файловой системы и запускает всё, что нужно, в фоне.
                                  В данный момент разрабатывается штука с рабочим названием bem server, для того, чтобы с проектами по архитектуре БЭМ можно было работать «из коробки».
                              +1
                              В бэм все должно(желательно) иметь свой класс, что бы не было контекстной зависимости. Что это значит на практике?
                              В бэм есть возможность распределения блока по не скольким блокам и дублирование элементов блока, и по этому, у каждого элемента блока должен быть класс, который отвечает за его внешний вид, вне зависимости от родителя. С одной стороны избыточно и непривычно, а с другой — удобно в использовании и легко читаемо и изменяемо.
                                +1
                                (возможно не заметил в ответах)
                                Ещё одна очень важная причина использования БЭМ — скорость рендеринга страницы.

                                Подробнее: уникальные одиночные селекторы (классы) отрабатывают быстрее чем множественные (.item_new быстрее .item.new или .items > .new). И чем больше вхождение уникальных селекторов, по сравнению с множественными, тем быстрее рендеринг.
                                +9
                                Отчасти, это сделано чтобы рендеринг был быстрее.
                                Раз так в 600 быстрее.
                                Чем более сложные классы вы используете — тем больше браузеру нужно произвести действий чтобы понять как отобразить тот или иной элемент.
                                  +3
                                  > Чем более сложные классы вы используете
                                  Тут 100% опечатка. Чем более сложные селекторы. На сложность классов браузеру как раз плевать.
                                    +1
                                    Ок, чем более сложные каскады вы используете…
                                      0
                                      На сложность классов браузеру как раз плевать.

                                      не наплевать, чем больше букв в имени класса — тем медленнее рендеринг
                                        0
                                        Даже так? И насколько серьезно?
                                          0
                                          что-то около нескольких процентов — не существенно, но есть
                                            +1
                                            По моим замерам разница между минимизированными и полными классами получалась константной, 20 мс.
                                  +2
                                  Домен 6-го уровня шикарный %)

                                  bem-method.toivonen.veged.dev.yandex-team.ru/pages/beginning/beginning.ru.html

                                  …ой, или это не та ссылка?
                                    +2
                                    Спасибо, я случайно не ту ссылку поставила.
                                    –1
                                    Когда кто-то говорит слово «БЭМ», в моей голове тут же всплывает этот комикс:

                                    image
                                      +4
                                      а какие вам известны аналоги БЭМ, которые существовали в момент начала разработки БЭМ?
                                        –3
                                        Из ваших слов можно решить, что после публикации БЭМа появились его аналоги, вдохновленные им. Если это так, мне было бы очень интресно о них узнать.
                                          +2
                                          не понимаю, почему такой вывод

                                          полных аналогов БЭМ (в том смысле в каком я его понимаю для себя) мне не известно — отсюда и вопрос (я с интересом бы их изучил)
                                            –4
                                            это в каком смысле?
                                              +2
                                              это не важно, я готов почитать про аналоги в ± любых смыслах
                                      +1
                                      ага, по моему опыту, верстка занимает несравнимо меньше времени, относительно остального. для большинства проектов это будет экономия на спичках, если вообще будет экономия. а если стили будут собираться для каждой конкретной страницы, если я правильно помню концепцию, то накладные расходы будут вообще огромны, потому что из десятков интернет-магазинов, которые я делал, файл со стилями редко превышает несколько сотен строк, там просто нет ничего сложного в разработке и отладке, особенно с накопленным опытом.
                                      мне кажется тут ситуация такая же как и с большинством фреймворков. то есть из проекта на миллиард можно сделать проект на десять миллионов, но и из проекта на десять тысяч получается тот же миллион. хотя, системный подход — это правильно в любом случае.
                                        +1
                                        Если говорить про CSS, то БЭМ утилиты позволяют автоматически создавать:
                                        — css для каждой страницы;
                                        — сss для всего проекта;
                                        — css с общими стилями для всего проекта и дополнительным уточняющим для каждой страницы;
                                        — сss со всеми стилями для конкретной или для группы страниц с уточняющими правилами для остальных.

                                        Если вы делали десяток интернет-магазинов, то уже на втором вы бы получили профит от использования БЭМ, а на десятом, скорей всего не написали бы и сотни строк html кода, потому, что было бы все готово ;)
                                          0
                                          В статье речь идёт не только о CSS-вёрстке, но также и о шаблонах и JavaScript компонентах. JavaScript может весить довольно много, если речь идёт о богатых приложениях.
                                          Статические файлы не обязательно собирать для каждой конкретной страницы. Можно объединить всё в один файл, или выделить какие-то общие (common) куски + постраничные файлы. Такие операции возможны благодаря командам bem decl merge и bem decl subtract (bem tools).
                                          В статье описана модель при которой каждая страница имеет свои CSS и JS файл, потому что такая модель прижилась у нас: мы проанлизировали поведение пользователей и скорость загрузки при различных вариантах, и этот оказался оптимальным. Дальше мы будем развиваться в следующем направлении: автоматический анализ статистики о том, какие страницы пользователи загружат вместе может влиять на сборку, внося логику в выделение этих «общих» кусков между страницами.
                                        +2
                                        В статье ни слова о логике блока или необходимых ему… таблиц в БД например.
                                        БЭМ применим только к организации шаблонов?
                                          +2
                                          БЭМ применим не только к организации шаблонов, но статья и так не маленькая и было очень тяжело осветить все темы. Мы будем продолжать улучшать документацию, в том числе и такого рода примерами.
                                          –3
                                          Да, БЭМ штука крутая, только я мануалил тут: bem.github.com/bem-method/html/all.ru.html
                                          Заюзал require.js с виджетами от jqueryUI, все в разы проще «вендорной» яндексовой методологии, по подобию масштабируемой архитектуры от azproduction
                                            +5
                                            Не смог удержаться. Вы полагаете, что _хорошее_ объяснение должно быть большим и с картинками? :-)

                                            Отчего такая проблема с формализацией мышления? Смотрите, вот я сейчас опишу вашу технологию.

                                            В основе ее 2 принципа:

                                            1. разбиение сложных сценариев на независимые от контекста мини-сценарии: специально организованные группы элементов (блоки);

                                            2. компиляция веб-проектов: генерация конечных файлов по шаблонам;

                                            Элементы DOM (как видимые, так и невидимые) могут логически быть объединены в единую группу — блок, которая реализует небольшой (законченный) сценарий, например, «меню» или «форма авторизации пользователя». В блок также включены стили и JavaScript-код, т.е. его поведение не зависит от окружения, поэтому
                                            a) его разработку можно изолировать;
                                            b) его можно использовать как «строительный кирпич» в сложных сценариях;

                                            Изоляция блока в контексте веб-страницы достигается правильным именованием: класс стиля элемента блока строится иерархически от имени блока до имени элемента, id селекторы не используются. Такой блок может работать в любом окружении.

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

                                            Далее, пару примеров, ссылка на ваши замечательные утилиты и — вуаля — все понятно.

                                            Человек прочтет и запомнит главное — принципы. Независимость от окружения и компиляция по шаблонам.

                                            Остальное — детали. Кому-то нужны, а кому-то — нет.

                                            А вашу простыню выбросить.

                                              +3
                                              У нас есть текст-конспект http://bem.github.com/bem-method/html/all.ru.html
                                              Пользователи писали, что им ничего не понятно.

                                              Блок — это не обязательно DOM-элементы. Могут быть абстрактные блоки, не представленные в DOM. Об этом в статье не написано, т.к. слишком сложно. Но и проводить параллель DOM-элемент — блок не нужно.
                                              Компиляция web-проектов — это всё-таки не про шаблоны.
                                              Под компиляцией подразумеваются какие-то действия, которые превращают «код для людей» в «код для роботов». Компиляция может быть применима и к шаблонам, и к статике. Сам факт наложения шаблонов на исходные данные компиляцией не является, тк это не пре-подготовка, на runtime.
                                                +2
                                                В своих собственных разработках мы постепенно отказываемся от XSL в пользу собственного JavaScript-based шаблонного движка XJST. Этот шаблонизатор вобрал в себя всё то, что нам нравилось в XSL, но реализует это с производительностью JavaScript как на сервере, так и на клиенте.


                                                Я правильно понимаю, производительность JS у вас получается выше чем скорость XSL трансформаций? Или о чем речь?
                                                  +3
                                                  Злесь речь идёт о JavaScript-bаsed шаблонизаторе, который мы разрабатываем и используем. В качестве входных данных используется JSON. Преобразования могут происходить везде, где есть JavaScript-интерпретатор: то есть и на сервере, и на клиенте. По сравнению с XSL производительность выше в 10 раз, по сравнению с TT2 — в 3 раза.
                                                  Более подробную информацию можно получить из выступления Сергея Бережного (veged) на YAC2011. Так же есть питерское выступление с таким же контентом, но другими вопросами из зала.
                                                  В основе лежит шаблонизатор XJST, он разрабатывается Open Source, вот репозиторий на GitHub.
                                                  Для работы непосредственно с блоками, есть «обёртка», дополнительный синтаксис, который называется BEMHTML. Непосредственно о синтаксисе можно узнать из поста про синтаксис BEMHTML. Конкретные блоки, разрабатываемые с применением этого шаблонизатора в Open Soruce — это библиотека блоков bem-bl (репозиторий на GitHub, разрабатываемый сайт). Описания реализации блоков публикуются в клубе на Я.ру (поиск по тегу bemhtml), так можно познать особенности.
                                                    0
                                                    Всегда считал добавление класса элементу или блоку избыточным, если в css отсутствует его описание
                                                      +1
                                                      Считается, что если у вас у элемента отсутствует CSS представление, то сам элемент является лишним.
                                                        0
                                                        вы говорите про элемент в контексте БЭМ?
                                                          +1
                                                          Имеется в виду DOM-нода.
                                                            +2
                                                            микроформаты? Или например динамический фрагмент текста
                                                              0
                                                              Не понимаю, что вы хотите спросить.
                                                        +2
                                                        У нас не бывает таких ситуаций. Если элемент понадобился, значит у него есть либо CSS, либо JS как-то с ним работает.
                                                          0
                                                          А что есть элементы имеют только смысловую (семантическую) нагрузку без каких либо выделений в дизайне?

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

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

                                                      Самое читаемое