Именование модификаторов как "_ключ_значение", на мой взгляд, излишне. На практике для нормального понимания абсолютно всегда достаточно написать только "_значение". Или кому-то в строке "*_disabled *_hidden *_big" будет непонятно, что "_disabled" — это о состоянии, "_hidden" — о видимости, а "_big" о размерах? Зачем писать лишние "_state", "_visibility" и "_size", когда все и без них очевидно?
Мы тоже так думали, пока не начали писать много JS, который работает с модификаторами и меняет их значения.
Вам надо изменить модификатор size со значения big на small — вы ищете модификатор по его типу, а не по значению. Типы модификаторов в пределах одного блока/элемента уникальны, а вот их значения могут совпадать.
Вы в имени элемента так или иначе используете ту же самую иерархию именования, что я описал выше, только в качестве разделителя пишете абсолютно нелогичный с моей точки зрения символ дефиса.
Дефис отделяет слова в составных именах, вне зависимости от того, блок это, элемент или модификатор.
Так при чем здесь тогда дефис? И, интересно, как бы вы написали такое — «news__list__item__link__image»?
news__list
news__item
news__link
news__image
Если хочется явно указать принадлежность item к list'у — news__list-item. Это по-прежнему будут два разных элемента, но их родственность определяется близкими именами.
У них там и организация файлов проекта, и представление блоков в JSON/XML, из которого потом автоматом генерируется HTML, и привязка к жаваскрипту, и даже инструменты для работы с этим.
Ещё до автоматической генерации HTML и привязки к JS мы использовали БЭМ (только тогда не называли это так, а называли независимыми блоками) и верстали это руками.
Да ну вы же должны понимать, что элементы с такими классами вроде приведённого выше яндексковского нельзя верстать и поддерживать руками и никто в здравом уме этим заниматься не будет.
И верстали, и поддерживали. От того оно всё развивалось и совершенствовалось.
Отказались от этого из-за всё большего количества js-кода, в котором классы могут получаться склейкой строк. После минимизации классов они получаются другими и js-код перестаёт работать.
Чтобы избежать этого, надо всю работу с классами вести через функции, которые скрывают конечные классы, позволяя при этом работать с блоками/элементами/модификаторами.
В этом случае до минимизации эти функции будут работать с одними классами, а после минимизации — с другими.
Это понятно как сделать, но руки сделать это ещё не дошли, есть более приоритетные задачи.
То есть продукт, в котором не учтена природа html и css, долгие годы их эволюции.
Поверьте, там учтена природа HTML/CSS и годы их эволюции.
И учтено так же, что HTML/CSS не предназначены для создания современных web-приложений и современных сайтов.
Создатели HTML/CSS не предполагали такого их использования и дальнейшее хаотичное развитие этих технологий академиками из W3C (в противоположность практикам) в конце 90x ничего хорошего в долгосрочное переспективе не дало.
Инициатива WHAT WG по созданию Web Applications 1.0 была хорошей, но опаздавшей на несколько лет и слишком долгой в разработке.
До создания БЭМ я много верстал, спецификации HTML и CSS были прочитаны мною много раз.
История создания БЭМ описана статьях в клубе и рассказана мной на Я.Субботнике в Минске. Поверьте, это был не быстрый и не лёгкий путь. Было много проб и ошибок, пока мы не выработали систему, которая позволяет верстать проекты так, чтобы их было легко поддерживать и развивать дальше, не превращая код в кашу.
Главные принципы хорошей вёрстки — это её семантичность, последовательность и читабельность.
А главные принципы поточной разработки — хорошая поддерживаемость кода, возможность быстрого внесения изменений, простота передачи кода от одного человека другому и быстрый вход нового человека в команду и проект.
Я понял, в чем у нас с вами основа непонимания. Я считаю less и sass такими же костылями, как и БЭМ, а вы нет.
Я с вами полностью согласен. Вообще, HTML/CSS не предназначался для современного их использования, для создания web-приложений. Если бы они дизайнились сейчас с нуля именно для этого современный web был бы другим. И делать web-приложения было бы существенно проще.
двойным подчеркиванием в именах, от которого нынешних программистов отучала пользоваться почти каждая книга по программированию.
БЭМ-методология не навязывает использование подчёркиваний для отделения одних сущностей от других, мы можете использовать любые другие сепараторы для отделения имени блока от имени элемента, и модификатора от блока/элемента.
Более того, возможность использовать любые другие разделители заложена в bem-tools и это можно настраивать как для всего проекта, так и для любого уровня переопределения в нём.
В статье же «Нет вложенных селекторов — т.е. никаких .class1 .class2{ display: none; }, всё определяется 1 (одним) селектором класса (плоская/одноуровневая структура стилей/селекторов).»
Да, но сомнительно, что для попапа будут семантичными классы b-popupa b-popupa__without-padding b-popupa_theme_ffffff b-popupa_direction_down b-popupa_is-bem_yes i-bem b-dropdowna__popup b-dropdowna__menu b-popupa_js_inited
Да, будут семантичны. Объяснить каждый класс отдельно?
Вам надо изменить модификатор size со значения big на small — вы ищете модификатор по его типу, а не по значению. Типы модификаторов в пределах одного блока/элемента уникальны, а вот их значения могут совпадать.
Как-то так: long-long-block-name__long-element-name_mod-name_value
news__list
news__item
news__link
news__image
Если хочется явно указать принадлежность item к list'у — news__list-item. Это по-прежнему будут два разных элемента, но их родственность определяется близкими именами.
Ещё до автоматической генерации HTML и привязки к JS мы использовали БЭМ (только тогда не называли это так, а называли независимыми блоками) и верстали это руками.
Отказались от этого из-за всё большего количества js-кода, в котором классы могут получаться склейкой строк. После минимизации классов они получаются другими и js-код перестаёт работать.
Чтобы избежать этого, надо всю работу с классами вести через функции, которые скрывают конечные классы, позволяя при этом работать с блоками/элементами/модификаторами.
В этом случае до минимизации эти функции будут работать с одними классами, а после минимизации — с другими.
Это понятно как сделать, но руки сделать это ещё не дошли, есть более приоритетные задачи.
Там много всего есть про оптимизацию конечного кода для браузера.
И учтено так же, что HTML/CSS не предназначены для создания современных web-приложений и современных сайтов.
Создатели HTML/CSS не предполагали такого их использования и дальнейшее хаотичное развитие этих технологий академиками из W3C (в противоположность практикам) в конце 90x ничего хорошего в долгосрочное переспективе не дало.
Инициатива WHAT WG по созданию Web Applications 1.0 была хорошей, но опаздавшей на несколько лет и слишком долгой в разработке.
До создания БЭМ я много верстал, спецификации HTML и CSS были прочитаны мною много раз.
История создания БЭМ описана статьях в клубе и рассказана мной на Я.Субботнике в Минске. Поверьте, это был не быстрый и не лёгкий путь. Было много проб и ошибок, пока мы не выработали систему, которая позволяет верстать проекты так, чтобы их было легко поддерживать и развивать дальше, не превращая код в кашу.
В Яндексе везде используется gzip и он даёт достаточно хорошее сжатие, чтобы не заморачиваться с этим.
Более того, возможность использовать любые другие разделители заложена в bem-tools и это можно настраивать как для всего проекта, так и для любого уровня переопределения в нём.
.block_mod_value
.block__elem_mod_value
Запись ".menu__item .link" означает: блок link вложенный в элемент item блока menu.
Замените b-popupa_theme_ffffff на b-popupa_theme_white, если вам так больше нравится.
Только сложно будет подбирать названия цветов, когда основным цветом темы будет какой-нибудь цвет типа #1ab3df.