BEM с человеческим лицом

    Звучная аббревиатура BEM пришла к нам из лабораторий Яндекса. Там, как и в случае с XSLT, применение BEM решили возвести в абсолют: под BEM'ом в Яндексе понимают целое семейство утилит и подходов, объединенных единой идеологией блочной архитектуры веб-приложений. Как любая тоталитарная система, BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом. И да, то самое чувство, когда читаешь официальные доки по BEM.


    Однако, как часто бывает в процессе эволюции больших систем, под давлением интеллекта и безлимитных сроков рождается технологический алмаз, настолько же маленький и самостоятельный, насколько и ценный, который огранят уже другие. Да, BEM с его спасительной строгостью — это явное откровение. Каждый, кто на моих глазах причащался, мгновенно становился счастливым. Однако, после первой волны наслаждения приходит осознание, что второй подход к этому снаряду может порвать ментальные связки по всему объему мозга. И вот уже слышны жалобы на слишком большую сложность освоения, на чрезмерную многословность, на (внимание!) увеличение количества мегабайт в HTML и CSS, и кто знает на что еще, не относящееся к делу.


    Соглашусь, трудно взять и начать писать BEM без разбега: и нотация глаз колет, и старые трюки не проходят, и думать приходится системно. И вообще, писали как-то годами без BEM'а и писать будем! А ведь для легкого и непринужденного преодоления порога вхождения нужно сделать всего два движения. Во-первых, понизить сам порог, смягчив BEM. И во-вторых, немного подтянуться самим. Тогда переход будет ровненьким и мы мягко вкатимся в эру читабельного и поддерживаемого CSS.


    Как мы дошли до жизни такой?


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


    Немного контекста нам не помешает, особенно исторического. Чтобы лучше понять куда нас ведет BEM, стоит сначала вспомнить, откуда мы идём. Итак, коротко приведу этапы становления стиля написания CSS.


    1995: Доисторическая эра


    <font color="red">

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


    2000: Примитивизм


    h3 { color: red }

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


    2005: Мы умеем в селекторы!


    div p.red h3 { color: red }

    Вот оно, зарево того пожара, в хаосе которого многие из нас сгорают на работе и по сей день. Тогда сайты уже умели делать не только студенты технических вузов, но и матёрые системные программисты. Они развивали фреймворки для бекенда, правильно проектировали базы данных, учились держать нагрузку, и даже создавали nginx! Но при этом совсем не умели и не хотели уметь CSS, или, тем более, этот ваш мерзкий JavaScript. Это привело к Bootstrap и jQuery.


    2007: Семантический CSS


    .article.new .title { color: red }

    В тред заядлых бекендеров врывается pepelsbey и несет доброе, светлое, чистое. Избавляет от тегов в CSS, открывает глаза на значение оных в HTML, вдохновляет на здоровый образ мысли и кода во фронтенде. Больше микроформатов и хорошего, годного веба, как его задумывал создатель.


    2010: Назад в каменный век вместе с Twitter Blueprint


    <p class="text-left clearfix red">

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


    2015: BEM


    .article__header--new { color: red }

    Оттягивали-оттягивали маятник в сторону быстрого старта и дооттягивались: в лоб прилетел жесткий до жестокости BEM. Пристыженные своей былой распущенностью мы готовы с головой броситься в терновый куст вычурного синтаксиса, лишь бы прикрыться могучим авторитетом и снова не думать про свой CSS.


    Основные перегибы: глобальных стилей не иметь, всё-при-всё упаковывать в элементы, к другим методологиям в глазки не заглядывать, свой HTML руками не трогать, чужой CSS домой не приводить. С таким строгим воздержанием и кодить сесть не встанешь.


    Один шаг назад, два шага вперед


    Что главное нам надо от BEM'а:


    1. Отсутствие коллизий
    2. Отсутствие коллизий
    3. И еще раз отсутствие коллизий

    BEM гарантирует отсутствие коллизий с помощью изоляции через пространства имён. Старая добрая концепция изолированных модулей. А с SASS вообще целый ООП. Конечно, сначала надо хорошенько подумать над разбиением на компоненты, но сперва давайте порадуемся дарам модульности:


    1. Читаемый и поддерживаемый код
    2. Переиспользование компонентов
    3. Простота тестирования
    4. Гармония с объектной природой JavaScript

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


    Нельзя, но если очень хочется…


    Как же можно очеловечить BEM? А очень просто: надо немного расслабиться, вернуться к здравому смыслу и вспомнить чувство фана от экспериментов. От простого к сложному, от очевидного к интригующему.


    Развидеть двойное подчеркивание


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


    .Article { … }
    .Article-title { color: red }

    Еще чуть-чуть и станет совсем похоже на сексуальный рубёвый DSL.


    Лаконичные модификаторы


    Если следовать правилу «никогда не нарушать границы пространств имён» и каждому блоку выделять по отдельному элементу, то есть вместо двух классов на ноду:


    <div class="Box Article">

    делать две ноды на два класса:


    <div class="Box"><div class="Article">

    то можно упростить именование модификаторов до привычных:


    .Article.new { … }

    А если добавить им префикс is-, то стили можно прямо читать вслух:


    .Article.is-new { … }

    Дело, конечно, не за префиксами модификаторов, это всего-лишь приятный бонус. Главное, что у блоков Box и Article не будет конфликтов даже если захотеть, и не придется ловить баги от того, что иногда модуль Article загружается раньше модуля Box и его стили получают другой приоритет. Но это и так очевидно же!


    Каскадность


    Можно вернуть в ваш BEM немного CSS:


    .Article.is-new .Article-title { color: red }

    Радует то, что дальше одинарного вложения BEM вас никак не пустит по определению (не повторять структуру HTML-дерева), так что такое уже невозможно:


    .Article .Article-title .Article-name { … }

    И конечно, совсем нельзя вмешиваться в чужое пространство имен:


    .Article .SubmitButton .Icon { … }

    Иногда, по старой плохой привычке очень-очень хочется так сделать. Но нельзя. Баланс с хаосом надо держать, а иначе вы нарушите основу целостности BEM'а и все старания пойдут насмарку.


    Мудрые замечания ArmorDarks и колкий стёб vintage просто вынуждают обратить внимание читателя на то, что деревья такими модификаторами не стилизуют: сломаются все дочерние элементы узла с таким модификатором. Стилизовать деревья надо еще строже — прямо по месту. Уверен, что читатели использующие рекурсивные структуры на вебе наслаждаются каскадностью CSS каждый день.


    Не использовать BEM


    Да, если на проекте всегда использовать BEM, то иногда можно BEM не использовать. В листовых компонентах можно использовать CSS свободной формы, не следуя никаким принципам BEM'а. Достаточно упаковать такой «непослушный» код в его собственный блок-изолятор и можно писать так:


    .WYSIWYG {
      h1 { … }
      p { … }
      ul li { … }
    }

    Строгая культура других модулей не позволит им вмешаться во внутренние дела модуля WYSIWYG и всё будет хорошо. Конечно, вложить какой-то еще компонент в «непослушный» компонент не получится без вероятности коллизий, так что такие «непослушные» блоки могут быть только листьями в дереве компонентов: их можно вкладывать в любые компоненты, но не любые компоненты можно вкладывать в них.


    Такой трюк бывает полезен не только в случае встраивания непредсказуемого пользовательского контента. Любой jQuery-плагин легко оборачивается в блок-изолятор и не благоухает своим CSS на всю страницу. Еще встречаются ну очень большие компоненты, например табличные таблицы в таблице таблиц, где строгое следование BEM'у заживо похоронит верстальщика под гнетом префиксов, так что дешевле всунуть Bootstrap. А еще случаются сложные формы, которые тоже удобнее и быстрее сделать листовыми элементами в блоках-изоляторах, а потом уже думать.


    Базовые стили


    Имеются ввиду размер шрифта, интерлиньяж, цвет ссылок, булиты списков и прочий reset/normilize.css. Большую часть наследуемых стилей возможно экранировать только с помощью жесткого переопределения всех этих стилей для каждого контейнера. Это выглядит излишним для всех, кто не планирует завоевать мир своей универсальной библиотекой абсолютно переносимых компонентов. Иногда, полезнее смириться с несовершенством текстового веба, чем тратить силы на борьбу с ветряными мельницами.


    Приняв это, становится очевидно, что старый добрый SMACSS подход к разделению стилей отлично портируется на BEM. Базовые стили остаются как есть. Layout становится просто специальным нелистовым компонентом. Модули, они же компоненты, они же блоки. Состояния проецируются на модификаторы один в один. Поддержка тем в BEM'е как бы вообще нативная. А состоянием в современном приложении должна управлять доменная логика и потом рендерить модель через React (руки прочь от jQuery!).


    Итого


    И вот уже стало всё знакомо и совсем не страшно. Можно даже сказать, что BEM с человеческим лицом — это старый добрый CSS для семантически правильного HTML, только легче поддерживается, проще пишется, лучше сжимается и быстрее исполняется.


    Голый BEM — это прокрустово ложе, но если его понять, принять и допилить, то он становится сиденьем истребителя — тесновато, но зато на нем можно летать!


    Письмо позвало в дорогу


    @ArmorDarks пишет:


    Возможно, Вам будет интересно: More Transparent UI Code with Namespaces

    Спасибо, еще как интересно!


    Насколько я понимаю, описанные приёмы помогают писать читаемый HTML, используя и пополняя готовый CSS. Например, утилитарный класс u-font-size-large применяется к ноде, чтобы сделать шрифт побольше, а t-light для того, чтобы применить к кнопке тему с более светлым фоном. В целом, если знать весь набор CSS правил, то HTML код действительно легко читать и писать. Однако, при смешивании стилей с одинаковым приоритетом вскоре потребуется !important, который описан в статье, как иногда приемлемый подход. На это я пойтить не могу, isagalaev воспитывал нас иначе.


    Меня в BEM тронула именно строгая изоляция стилей от HTML. Раз CSS всё равно надо знать и понимать, то почему бы, наконец, не убрать всю работу со стилями в CSS? Например, если использовать .u-font-size-large для заголовка статьи, то так:


    %u-font-size-large { font-size: x-large }
    .Article-title { @include %u-font-size-large }

    В статье приводится пример, что могут потребоваться дополнительные мелкие правки стилей, даже тысячи их. И автор сразу верно возражает, что такие мелкие правки говорят о проблемах с дизайном. Но надо так надо, давайте добавим .u-font-size-large-xx и не придется плодить всякие .article__title--large-xx, .post__title--large-xx, .user__title--large-xx. Здесь я на стороне BEM'а с его explicit против implicit, и вот почему.


    Во-первых, вот нашли вы в чужом коде <div class="Article-title is-xx"> навели инспектором, и первые же стили будут именно модификатора, как наиболее специфичные. В случае .u-font-size-large-xx придется немного полистать и подумать. Далее. Если вы определили .Article-title.is-xx через наследование @extends .u-font-size-large то увидели в инспекторе же и .u-font-size-large, и другие блоки, использующие этот же суперкласс. А если вы предпочли @include, что в этом случае, возможно, логичнее, то уже прыгнули сразу в файл Article.scss и вот она логика вашего модификатора, возможно, даже более сложная, но наглядная и в терминах SCSS.


    Во-вторых, не нужно думать о том, какие могут быть сочетания разных .u-*, вот же они все для конкретно этого блока — лежат в файле Article.scss гарантируя правильную семантику. Все возможные сочетания модификаторов из какой-то библиотеки прямо перед глазами, хоть и несколько многословно. Считаю что это спасительный детерминизм. Такой вот Go vs C++.


    В-третьих, когда меняется стиль, не нужно лезть в .erb, .inc, .php, .js шаблон и заменять .u-font-size-large на новый .u-font-size-large-xx во все места использования компонента Article, достаточно перекомпилить SASS. Конечно, в случае добавления семантически нового модификатора для нового состояния доменной сущности шаблоны таки придется поправить. Но это уже будет законная, понятная правка, с адекватным комментарием в коммите, со строкой в документации для нового состояния, с тестами без привязки к CSS.


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


    А для всего непредсказуемого, что меняется слишком часто или содержит в себе ну очень много элементов и/или модификаторов есть листовые блоки, нарушающие все законы BEM'а, кроме пространства имен.


    Спасибо еще раз, лавина сошла.


    @ArmorDarks пишет:


    Такой подход (o-btn c-btn c-btn--positive qa-modal-accept прим. авт.) позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.

    Вот она ключевая фраза, спасибо вам за неё. Это водораздел, пропасть посреди, государственная граница, горизонт событий, наконец. Именно эта фраза вбивает кол между двумя совершенно противоположными и одновременно равноправными и дополняющими друг друга подходами к верстке. Лично я нахожусь на фанатичной стороне «поддерживать и масштабировать годами один сложный проект, постоянно меняя CSS», а ваша крайность «заготовить прочный фундамент и годами строить на нем большой массив, не касаясь CSS». Это как паттерны против фреймворков. Абстрактное против конкретного. Используя BEM как подход, люди строят библиотеки компонентов как фреймворки. Статья про подход. Пора бы уже автору прослушать курс теории категорий.


    Кстати, как верно подсказывает документация к Bootstrap, такой фундаментальный CSS-фреймворк должен быть read-only, прямо как до появления CSS и тега <font> был веб: берёшь — и пишешь, используя только уже готовые и доступные теги HTML, не думая про CSS. Работало же. А вот если таки позволять менять такой CSS-фреймворк на уровне процесса, то есть по требованию бизнеса… GOTO 1.

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

    Оцените своё отношение к BEM по 128-бальной шкале:

    Поделиться публикацией

    Комментарии 55

      +1
      Похоже на rscss.io, только там более продуманно :-)
        0
        Tag selectors are fine, but they may come at a small performance penalty…

        Первая часть утверждения в комментариях не нуждается, но вот что это за проблемы с производительностью селекторов в 2016 году?
          0
          Посмотрел их доку, а там почти то же самое, что получилось у меня в ходе просеивания БЭМа. Плюс-минус мелкие детали.
          +7
          Красивые у вас примеры, в реальной жизни все не так живописно.

          Немного утрируя, я сделал BEM classname generator, который наглядно демонстрирует почему лично я недолюбливаю BEM.

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

            –1
            .option-environment__competition-factory--increase-factory

            [my_environment_competition="increase"]
              +2
              Все зависит от фантазии разработчиков, но у нас на проектах по большей части хватает коротких, лаконичных названий блоков, изредка всплывают названия блоков/элементов (второе намного реже) из двух слов.
                0
                Спасибо за пример. Проблема действительно имеет место быть.
                Тем не менее, не могу не отметить, что BEM classname generator местами избыточно утрирует ситуацию. К примеру, многие генерируемые ним элементы должны быть раздельными блоками, что не только сокращает название в два раза, но и делает их портативными.
                В модификаторах также крайне редко встречаются такие длинные названия.
                  +1
                  Уже год как пробую и тестирую различные варианты нейминга, и пришел к выводу, что мне не хватает еще одного уровня вложенности, я называю это «компонент». А для самих элементов часто хватает семантических имен (link,string,btn и т.д.). также сделал на этом принципе свой фреймворк. Кстати собираюсь статью написать как раз про него, там как раз будет две основных темы затронуто «Модификация БЕМ и Плейсхолдеры в SASS».
                  А выглядит это так «Компонент--модуль__элемент._модификатор». Кстати благодаря плейсхолдерамя избавился от необходимости писать несколько классов. И главное правило это то что тег имеет только один класс, и модификаторы.
                    0
                    Возможно, Вам будет интересно: http://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/
                      0
                      О как, Интересно было почитать. Особенно про автоподстановку. Кстати даже префиксы местами очень похожи же у меня например так.
                      obj-: Кастомизарованные элементы
                      Также есть сразу 3 зарезервированных компонента obj-header, obj-footer, obj-widget.
                      ui-: Стандартный набор элементов интерфейса.
                      layout-: Обвертки.
                      А вот тема cms-content тоже есть раньше этот блок называл wysiwig теперь typography.
                      А вот что не понравилось, и от чего как раз хотел избавиться я, так как на одном проекте вышел ад. "c-btn c-btn--positive qa-modal-accept"
                        0
                        Это еще и не полная версия — должно быть o-btn c-btn c-btn--positive qa-modal-accept

                        Зато это позволяет очень гранулированно использовать классы и конфигурировать практически что угодно на лету.

                        Такой подход используется в нашем фреймворке, который используется в нашем генераторе статических веб-сайтов\стартер-ките. Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.
                          0
                          Я это реализовал через плейсхолдеры, и миксин для их подключения, где все модификаторы передаем в качестве параметров.
                          К примеру:
                          %ui-btn {
                          &%base { display:block; color:blue; font-size:16px;padding:10px;}
                          &%red {color:red;}
                          &%small {font-size:10px; padding:4px;}
                          }
                          И подключение:
                          .obj--newsbtn { include extendUI('ui-btn',('btn'));}
                          .obj--news
                          btn._readmore { include extendUI('ui-btn',('btn','red','small'));}
                            0
                            Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.

                            Вот она ключевая фраза, спасибо вам за неё. Еще раз ответил вам в конце статьи.
                          0
                          Мне тоже было интересно, спасибо. Ответил на идею поста в конце статьи, конечно, продолжая нахваливать BEM.
                          Мы понемногу становимся соавторами :)
                      +1
                      Применим ли БЕМ для организации JS кода в приложении? Я встречал только про верстку, html, css. Но есть люди, которые применяют это для структурирования основного кода SPA и переубедить их никак не получается… Подскажите плиз может где-то это описано. (я совсем не гуру БЕМ).
                        +1
                        БЭМ для JS — это конечно перегиб. БЭМ нужен для организации модульности и избавления от коллизий, а в таких языках как JS для этого есть свои средства. Сейчас даже классы появились.
                          +1
                          По моему опыту, БЭМ в JS применим только как наследие от CSS, когда нужно работать с классами, имеющимися в верстке.

                          БЭМ в первую очередь борется с глобальными колизиями, проблемами specifity, отсутсвием нативной модульности. Мне кажется, избыточно пытаться применить эту методологию в языке, который не имеет таких проблем (при правильной организации кода).
                            0
                            конечно БЭМ применим для JS кода! главная суть БЭМ-а это «многоязычность» https://ru.bem.info/method/key-concepts/#Технология-реализации
                            вот документация про основную реализацию https://ru.bem.info/articles/bem-js-main-terms/ https://ru.bem.info/technology/i-bem/v2/i-bem-js/
                            если появятся дополнительные вопросы всегда можно получить ответ на форуме https://bem.info/forum/
                              0
                              вот ещё пара докладов по теме:
                              https://events.yandex.ru/lib/talks/689/
                              https://events.yandex.ru/lib/talks/302/
                                0
                                Спасибо, второй понравился больше, люблю ретроспективы ;)
                                 
                                Я сам из лагеря FLUX года эдак с 2008 и jQuery никогда не касался, поэтому не могу полноценно оценить все преимущества, но такие фундаментальные вещи, как автоматический вызов деструкторов, отсылающий нас к модному ныне React.js с его componentWillUnmount(), а также onclick="{json}" почти в точности повторяющий горячо любимые мной реактовские же this.props вызывают глубокое уважение.
                                Нельзя голосовать (положительно!) за пользователей, у которых нет размещенных публикаций

                                WTF? :)
                              0
                              БЭМ — был полезен, но морально устарел. При современной компонентной разработке фронтенда, с возможностью инкапсуляции и байндинга стилей — вообще не нужен. Народ по иннерции пихает его куда можно и куда нельзя, но пора уже посмотреть на него свежим взглядом. Главная польза БЭМа в том, что в свое время он показал, что в стилях — должен быть порядок и за это ему спасибо.
                                0
                                Это вы про Shadow DOM и Web Components? Да, прийдет их время, и в начале статьи появится «не читайте этот устаревший бред, а используйте X». Но пока CSS решае.
                                  0
                                  Ну про это конечно тоже и даже в первую очередь, но и в реактах с ангулярами также БЭМ уже не актуален. Достаточно создавать стайл-скоуп (блок) по имени компонента и использовать препроцессоры для порядка с элементами. Модификаторы переезжают в параметры компонента.
                                    0
                                    Модификаторы переезжают в параметры компонента.

                                    Интересная мысль. Чувствовал что-то подобное, но так и не нашел способа избавиться от модификаторов с помощью реакта. Поделитесь, пожалуйста, еще парой крошек мудрости, дальше я по-японски разовью тему сам :)
                                0
                                CamelCase нотация для блоков радует глаз заядлых си-плюс-плюсщиков/яваскриптистов/рубистов
                                «радует глаз» — так себе аргумент. Иногда привычки надо менять. Классы в css не чувствительны к регистру, а значит рано или поздно вы столкнётесь с проблемой конфликта идентификаторов отличающихся лишь регистром. Но не это самое страшное, а привычка к нечитаемой верблюжьей нотации: `ACMESubmitButton`, вместо более читаемой `acme-button-submit`.

                                Главное, что у блоков Box и Article не будет конфликтов даже если захотеть, и не придется ловить баги от того, что иногда модуль Article загружается раньше модуля Box и его стили получают другой приоритет.
                                Конфликты будут на уровне элементов: `.Order .Button.is-submit` и `.ButtonGroup .Button.is-submit`. Проблема порядка подключения в случае bem легко решается сборщиком, отслеживающим зависимости в CSS.

                                .Article.is-new .Article-title { color: red }
                                Банальный контрпример — дерево. Куча вложенных друг в друга одинаковых блоков и каждый пытается задать цвет для всех вложенных заголовков.

                                Большую часть наследуемых стилей возможно экранировать только с помощью жесткого переопределения всех этих стилей для каждого контейнера.
                                Не надо экранировать то, что должно наследоваться. Например, блок не должен лезть со своим уставом (шрифтом) в чужой монастырь (страницу), а должен использовать те шрифты, что есть на странице. Но он может попросить шрифт «чуть-чуть по меньше» или подходящего его фону цвета.
                                  +8
                                  Классы в css не чувствительны к регистру

                                  Нечувствительны, говорите?

                                    0
                                    Перепутал с атрибутами, да.
                                    +1
                                    Классы в css не чувствительны к регистру
                                    Вообще-то, селекторы регистрозависимы
                                    +1
                                    Метод изложения на 5+
                                    Особенно порадовало:
                                    >и не благоухает своим CSS на всю страницу

                                    Немного не понял по поводу «Всунуть Bootstrap».
                                    Разве если его подключить, когда половина уже сверстана, он не поломает хоть что-нибудь тем, что напрямую стилизует элементы h1,p и т.д.?
                                    Как можно его использовать изолировано в каком то блоке?
                                      +1
                                      Поломает и сильно.
                                      Бутстрап вообще ужасная кака, но на него много всяких штук завязано и приходится его терпеть.
                                      У меня в проекте отдельная папка с файлами переопределения бутстраповских стилей поверх БЭМ.
                                      Тут два стула — или ты делаешь подобный грязный хак (фу-фу-фу так делать, но приходится), или выкидываешь бутстрап и всё что он за собой тянет (много чего) и пишешь всё это с нуля (весьма накладно по времени).
                                        0
                                        Спасибо! Стараюсь оживить скучные темы драмой :)
                                        Отвечу на «всунуть Bootstrap». Если подключить Bootstrap, обернув его в класс-как-бы-блок с помощью SASS, то он будет ломать что-либо только внутри элементов с этим классом-блоком.
                                          0
                                          Имеете в виду что то типа?
                                          .wrapper
                                          {
                                          import 'ALL_BOOTSTRAP_CSS.css';
                                          }

                                          ?? (синтаксис понятное дело от балды. Теперь сижу думаю, как то же самое на less сделать)
                                            0
                                            Да, именно это.
                                            .BootstrapSoup {
                                              @import 'bootstrap';
                                            }

                                            при условии наличия файла _bootstrap.scss получим:
                                            .BootstrapSoup fieldset { … }
                                            .BootstrapSoup .container { … }
                                            .BootstrapSoup .modal-open { … }

                                            и дело в шляпе!
                                        0
                                        Из статьи может показаться, что БЭМ появился в 2015 году, как следствие несовершенства всех остальных подходов, а не 10 лет назад, как попытка взять под контроль табличный говнокод в Яндексе. В целом, очередная раздача костылей под красивое описание годных практик, которым БЭМ противоречит.
                                          0
                                          Из статьи может показаться, что БЭМ появился в 2015 году

                                          А может и не показаться. Яваскрипт тоже запилили 20 лет назад, а когда он выстрелил.
                                            0
                                            Хотите сказать, что БЭМ в 2015 году выстрелил? Сомневаюсь, что БЭМ вообще когда-либо выстреливал, если вы не про выстреливание себе в ногу.
                                              +2
                                              Мсье, вот вам краткий список говнокодящих стрелков в ноги для размышлений:

                                              Google:
                                              https://github.com/google/material-design-lite/wiki/Understanding-BEM
                                              https://developers.google.com/web/fundamentals/performance/rendering/reduce-the-scope-and-complexity-of-style-calculations

                                              Adobe:
                                              http://topcoat.io/

                                              Гайды от правительства США:
                                              https://playbook.cio.gov/designstandards/getting-started/

                                              Еще гайды:
                                              http://www.joelambert.co.uk/article/bem-guidelines/

                                              Снова гайды:
                                              http://cssguidelin.es/

                                              https://github.com/search?utf8=✓&q=bem — более 2k репозиториев по запросу bem

                                              https://www.npmjs.com/search?q=bem — 600 пакетов по запросу bem

                                              Статьи:
                                              http://www.integralist.co.uk/posts/bem.html
                                              http://blog.kaelig.fr/post/48196348743/fifty-shades-of-bem
                                              https://css-tricks.com/bem-101/
                                              http://montagestudio.com/blog/2013/10/24/BEM-syntax-with-ux-in-mind/
                                              http://webdesign.tutsplus.com/articles/an-introduction-to-the-bem-methodology--cms-19403
                                              https://medium.com/@andersonorui_/bem-sass-and-bootstrap-9f89dc07d20f#.rxjgrtbmt
                                              http://www.creativebloq.com/css3/create-modular-and-scalable-css-9134351
                                              http://code.tutsplus.com/articles/how-were-using-modules-to-organize-our-front-end-code--cms-22702
                                              https://davidwalsh.name/starting-css
                                              https://www.viget.com/articles/bem-multiple-modifiers-and-experimenting-with-attribute-selectors
                                              http://www.juliecameron.com/blog/2013/11/06/bem-naming-for-sass-color-variables-what1/
                                              https://www.bensmithett.com/bem-modifiers-multiple-classes-vs-extend/
                                              http://blog.8thlight.com/nelsol-batalla/2014/08/01/bem-basics.html
                                              http://www.sitepoint.com/bem-smacss-advice-from-developers/
                                              http://blog.14islands.com/post/70395374262/our-principles-for-bem-sass
                                              http://vanseodesign.com/css/block-element-modifier/
                                              http://blog.moove-it.com/mastering-css-bem-and-itcss/

                                              И так далее. В среднем блогмониторинг приносит пару новых статей про БЭМ в день.

                                              Ну а из местных костылятелей табличного говнокода, кроме Яндекса могу предложить к изучению опыт
                                              * mail.ru (https://habrahabr.ru/company/mailru/blog/250783/ + https://habrahabr.ru/company/mailru/blog/142193/ + https://habrahabr.ru/company/mailru/blog/263221/)
                                              * http://www.rambler.ru/
                                              * Альфа-банка (https://github.com/alfa-bank-dev/ui)
                                              * http://learn.javascript.ru/

                                              Ну и так далее.

                                              PS: вы в предыдущем комментарии упомянули годные практики, которым БЭМ противоречит. Поделитесь?
                                          +1
                                          Я бы еще посоветовал использовать двубуквенный префикс, это позволит избежать конфликтов при подключении компонентов от разных вендоров.
                                            0
                                            Как писать БЭМ адекватно без тупых модификаторов и замороченного синтаксиса я писал в статье на блоге
                                              +2
                                              Спасибо за статью

                                              .Article.is-new { … }

                                              Здесь не все так гладко:

                                              1. Из такого чейнинга при изучении html-кода совершенно непонятно, на что влияет класс `.is-new` — на `Article`? Или может быть на какой-то иной блок в данной html-ноде? Ведь на одной ноде может быть несколько блоков или элементов.
                                              2. В случае наличия на одной html-ноде нескольких блоков это может привести к неприятным коллизиям.
                                              3. БЭМ не только пытается решить проблему коллизий, но еще и проблему specifity. И вот такой вот чейнинг как раз возвращает эту проблему. И во многих местах она серьезней, чем кажется

                                              Можно вернуть в ваш BEM немного CSS:
                                              .Article.is-new .Article-title { color: red }

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

                                              .article--is-new .article-title { color: red }

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

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

                                              Я бы сказал, для классов используется kebab-case не потому, что он легче читается (это ведь субъективно), а просто как наследие самого html и css, которые как языки по умолчанию являются kebab-case (http-equiv, data-attribute в HTML, text-shadow, background-color в CSS). Консистентность.
                                                +1
                                                Ведь на одной ноде может быть несколько блоков или элементов.

                                                Да, как раз в статье это условие специально уточнено прямо рядом с обсуждаемым примером:
                                                Если следовать правилу «никогда не нарушать границы пространств имён» и каждому блоку выделять по отдельному элементу…

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

                                                Да, вы совершенно правы. Выше vintage привел в контр-пример дерево. Добавлю это исключение в статью. Вообще, рекурсия средствами CSS решается не очень красиво.
                                                Про kebab-case тоже всё верно, тут я посолил по вкусу. С другой стороны, либо CamelCase либо подчеркивания, которые отправляют меня назад в Perl. А на смесь двойных и одинарных тире я не согласен совсем.
                                                  0
                                                  Вот еще вспомнил хорошую статью по теме контекстуального стилизирования http://csswizardry.com/2015/06/contextual-styling-ui-components-nesting-and-implementation-detail/
                                                  0
                                                  Вот еще доклад со схожей темой: https://www.youtube.com/watch?v=nwS7M2L07uU. Идеи коррелируют и синтаксис интересный.

                                                  Однако, я бы все таки воздержался от таких решений. Слишком много узких мест.
                                                    +1
                                                    Вот ведь что странно: я согласен с основным тезисом автора, что БЭМ — это хорошо, а практически с каждой отдельной фразой — нет. Как так получилось-то? :)

                                                    Попробую аргументировать.

                                                    > BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом

                                                    Можно, пожалуйста, ссылки и цитаты с bem.info или какой-либо статьи/выступления от Яндекса, где рекомендации как-то противоречат здравому смыслу или как-то мешают на небольших проектах?

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

                                                    > И да, то самое чувство, когда читаешь официальные доки по BEM.

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

                                                    > 2015: BEM

                                                    Например, вот Я.Субботник 2011 — https://events.yandex.ru/lib/talks/217/
                                                    А вот пост в клуб БЭМ за 2009: https://ru.bem.info/forum/-46/
                                                    Так что все началось сильно раньше Бутстрапа и примерно в тот момент, когда в интернетах стало модно верстать семантично и валидно ;)

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

                                                    Покажите, где вы про это узнали? Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками (тем же Бутстрапом при желании и делюсь ссылками на решения, где БЭМ объединяют с Реактом, Ангуляром, you-name-it).

                                                    И даже HTML, грешным делом, бывает руками пишу, хотя и в самом деле есть способы поэффективнее ;)

                                                    > Развидеть двойное подчеркивание

                                                    Тут, пожалуй, сложно не согласиться, тем более что ровно про эту возможность подробно написано на bem.info в разде про нейминг: https://ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
                                                    Там же приводится ссылка на инструмент, позволяющий писать вообще как угодно.

                                                    > Лаконичные модификаторы
                                                    На первый взгляд звучит неплохо, но есть проблема: https://ru.bem.info/faq/#Почему-в-БЭМ-не-рекомендуется-использовать-комбинированные-селекторы-для-создания-css-правил-к-модификатору

                                                    Если для вас экономия времени на набор нескольких символов перевешивает возникающие в результате проблемы — дело ваше. БЭМ не запрещает, но «не рекомендует». И плюс-минус ваши же примеры приводятся на bem.info ;)

                                                    > Каскадность

                                                    Строгие читатели отругали нас за использование слова «каскад» не по спеке. На самом деле это про вложенные селекторы.

                                                    Так вот, тут снова БЭМ не запрещает, а говорит, что использование «нежелательно», объясняет почему и тут же приводит примеры, когда это оправдано: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы

                                                    Впрочем, мы регулярно пытаемся в комментариях к статьям на Хабре рассказать, как все на самом деле (например, вот тут про это же пишет Харисов https://habrahabr.ru/post/151931/#comment_5165248), но люди упорно пишут новые статьи, где говорят то же самое, что и мы, но как будто это они только что придумали, а в Яндексе зачем-то едят кактус :)

                                                    Еще немного мифов я попытался развенчать в этом посте: https://ru.bem.info/forum/158/
                                                    Настоятельно рекомендую.

                                                    PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
                                                      0
                                                      Со всеми пунктами согласен

                                                      PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы

                                                      Люди спрашивали, применим ли БЭМ для организации JS кода и насколько это эффективно. Это несколько иное. Или я что-то упускаю?
                                                        0
                                                        Это несколько иное.

                                                        Мне вот очень интересно мнение тех кто в теме применим ли БЭМ для организации JS кода. Web Components это круто, но вопрос не об этом. Смешивание js и css, html в один компонент это очень крутая штука. Сейчас, например, почти тоже можно сделать используя webpack и это очень и очень удобно и классно (моё скромное мнение). Но JS код структурированный по БЭМ? Может кто-то так использует? может кто-то имеет пример такого кода? Интересно на сколько это удобно для разработки, поддержки, больших проектов, какие фреймворки и т.д.
                                                        Буду очень благодарен если кто-то поделится опытом такого совокупления. Спасибо.
                                                          +1
                                                          Работал с bemjs — так себе удовольствие.
                                                          Сам по себе бэм — число для css. Но в основе у него более фундаментальные идеи, которые можно применять много где:
                                                          1. разбиение на независимые компоненты (блоки, классы)
                                                          2. плоская структура компонент (элементы, модификаторы, свойства)
                                                          3. переопределение реализаций вложенных компонент объемлющей (миксование классов на элементе, переопределение свойств при создании)
                                                            0
                                                            По запросу bemjs нашел вот такой пакет https://www.npmjs.com/package/bemjs от некоего https://github.com/Gertt
                                                            Пользоваться не доводилось. Речь о нем?
                                                            0
                                                            Я боюсь, что мы по-разному понимаем термины. Что вы вкладываете в «структурированный по БЭМ»?

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

                                                            Было

                                                            styles/
                                                                button.css
                                                                input.css
                                                            js/
                                                                button.js
                                                                input.js

                                                            Так делает, например, Бутстрап.

                                                            А по БЭМ станет

                                                            button/
                                                                button.css
                                                                button.js
                                                            input/
                                                                input.css
                                                                input.js

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

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

                                                            Подробно про все это опять-таки есть на bem.info, со всеми возможными вариантами (пишу на случай, если кто-то опять захочет сказать, что в БЭМ строго и ни шагу в стороны — вариантов предостаточно): https://ru.bem.info/method/filesystem/

                                                            А если речь про написание собственно кода, то могу предложить вот такой пост на тему для начала https://ru.bem.info/forum/163/

                                                            Дальше можно смотреть в сторону https://github.com/hoho/jquery-bem

                                                            А если хочется по-настоящему серьезно подойти к вопросу, то https://ru.bem.info/technology/i-bem/
                                                            +1
                                                            Идея БЭМ в плане организации JS кода в своей основе совпадает с идеей Web Components — разделение интерфейсы на компоненты/блоки так, чтобы все технологии этого компонента (CSS, JS, шаблоны, тесты, etc) были рядом и могли быть с легкостью переиспользованы на других проектах.

                                                            Если смотреть на частности, то Web Components достигает этого специальными требованиями к браузерному API, а текущие реализации БЭМ — тем фактом, что JS использует те же селекторы, что и CSS. Плюс, в зависимости от реализации, добавляются еще всякие хелперы про установку/снятие модификаторов, чтобы было удобно выражать состояние компонента (как state в Реакте, только используется с 2008 года), плюшки про подписку на событие изменения модфикаторов и прочие полезности. Но еще раз повторюсь, что это уже вопрос конкретного решения, которое вы будете использовать, методология же говорит лишь про расположение на файловой системе и то, что следует использовать общие селекторы на блоки/элементы, а состояние выражать через модификаторы.
                                                            0
                                                            Непросто отвечать человеку живущему технологией, о которой знаешь со стороны, чтобы и в лужу не пёрнуть, и таки себя показать.
                                                            рекомендации как-то противоречат здравому смыслу

                                                            Читайте внимательно: здравому смыслу небольших проектов. Предположим, что за освоение всего БЭМ тулсета мне оному еще зарплату заплатят. А вот навязать это всей команде я точно не смогу. Даже учитывая потенциальную пользу. Послушайте, даже пресловутый React, который решает главную фундаментальную проблему stateful интерфейсов и тот поди внедри среди не Ph.D.
                                                            которые используют верстку по БЭМ

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

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

                                                            И это говорит, что не зря я всем твердил с 2007 года: «хотите настоящей работы, друзья, идите на собеседование в Яндекс». Двое из них у вас работают. Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM». То есть вот оно всемирное признание. Было ли оно в 2009? А в 2011?
                                                            Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками

                                                            Теперь и я вам помогаю. Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
                                                             
                                                            Далее согласен со всем тем, что БЭМ может позволять. Об этом и статья. Вам это очевидно, а, например, англоязычным авторам не очень. И в целом, реакция на строгость БЭМа строго негативная. Вот допилю статью, переведу и пойду показывать своим паникёрам.
                                                             
                                                            P.S. В комментах часто бывает много противоречивых параграфов, затем я и пишу на Хабр, за точками зрения, за ошибками восприятия, за хорошими контр-примерами (дерево ломается на вложенных селекторах, например). Этот опыт помогает лучше объяснять новым людям то, во что веришь и что любишь. Спасибо Яндексу и вам за БЭМ!
                                                              0
                                                              > Читайте внимательно: здравому смыслу небольших проектов.

                                                              Так ведь это… я и для небольших проектов никакого вреда от применения БЭМа не вижу. Он есть? :)

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

                                                              > не путать БЭМ с вёрсткой по БЭМ

                                                              Звучит примерно как не путать чаепитие с чайной церемонией ;)
                                                              Предполагается, что есть такие тонкие ценители, которые могут определить ту грань, когда вот только что была верстка по БЭМ и тут опа-па и стал БЭМ?

                                                              Я, конечно, догадываюсь, что под этим разделением понимают использование JS фреймворка, оперирующего блоками, декларативного шаблонизатора, опять же работающего с блоками, и сборки, понимающей, как собрать нужные блоки с файловой системы в общий бандл. Но вот, скажем, стали мы собирать БЭМ-проекты на gulp (https://ru.bem.info/forum/782/) или, допустим, Webpack (https://ru.bem.info/forum/774/) — это теперь не БЭМ, а верстка по БЭМ? :)

                                                              > для новичка поезд с легким освоением деталей уже ушел

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

                                                              Сейчас методологический раздел https://ru.bem.info/method/ содержит те самые 5 страниц + историю появления, так что поводов для паники быть не должно. Но мое предложение в силе — если есть конкретные моменты, которые звучат непонятно — буду рад про них узнать и улучшить.

                                                              > Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM»

                                                              Вот, скажем, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ англоязычный пост за январь 2013, где Гарри Робертс ссылается на Николаса Галлахера и делится своими соображениями про БЭМ.

                                                              > Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.

                                                              Смотря что вы подразумеваете под «стилем написания CSS». В документации на bem.info приводятся примеры разных вариантов нейминга, разных схем организации файловой структуры, примеры с вложенными селекторами, в общем, все то, про что вы в статье пишите. Однозначно мы, разве что, утверждаем, что селекторы на id не нужны никогда ;)
                                                                0
                                                                У вас волчанка, сэр :)
                                                                 
                                                                Вы настолько привыкли защищать и пропагандировать БЭМ, что делаете это уже по инерции даже в статье, которая служит ровно той же цели. Тон статьи нарочно таков, будто я вовсе не фанат БЭМа, а наоборот, напуган и растерян, что я вижу те же странности, что и неподготовленный читатель, а дальше нежно и плавно вкладываю стержень новых знаний по самые уши. А ушлые БЭМеры, котрые сидит на нем уже пятый год и статью-то не откроют — гляньте какие хилые просмотры по меркам хабра.
                                                                 
                                                                И большое спасибо за ваши комменты — следующую статью буду писать только перечитав их все.
                                                                  0
                                                                  Проще говоря, это завуалированный пиар. Надо было тщательней маскировать свой фанатизм. Демонстрация недостатков не имеет отношения к реальной жизни. При этом захваливание носит откровенно религиозный характер. Может тогда и просмотров было бы больше. Следующую статью писать не надо.
                                                                    0
                                                                    Вы бы лучше к своей статье комментарии оставляли. Вам там много хороших вопросов задали.
                                                                      0
                                                                      Чем лучше, пытаетесь меня просто прогнать? Если вам что-то не нравится в моей статье, можете зайти и покритиковать. Ваша статья от этого лучше не станет. Снос кармы лишь подтверждает ее посыл.

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

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