Содержание
На самом деле БЭМ’ом я заинтересовался достаточно давно, приглянулась идея, попытался в неё вникнуть, попытался применить на практике, но вот как-то не пошло, не знаю почему. Сделал несколько подходов, но в итоге мой проект превратился в жуткую мешанину из попыток внедрения БЭМ’а, и «идей кристальной семантичности HTML + CSS» (на которые я перешел, разочаровавшись в БЭМ’е). По факту меня это радует печалит до сих пор и приносит ежедневную радость боль в работе над проектом. Всплывшие статьи из ката и коментарии к ним вызвали во мне бурю эмоций по вопросам семантичности верстки, устройства браузеров, БЭМ’а, препроцессоров и всех, так или иначе касающихся темы идеологий, методологий, техник и прочего. Так как мой личный подход к применению БЭМ’а провалился, но вполне логичные обоснования применения методологии все еще бродили в голове, то в каждой статье и каждом комментарии я пытался найти истину, которая так или иначе дала бы ответы на мои вопросы и окончательно бы сформировала лично мое отношение к БЭМ’у. Как ни странно в один прекрасный момент это произошло. Как это произошло и почему я попытаюсь донести до вас.
Рассмотрим типичный холивар
Действующие лица
Семантист — отрицающий БЭМ.
Бэмер — приверженец БЭМ.
Акт I: Начало
Семантист
Напишем структуру менюшки.
<nav>
<ul class="top-menu">
<li><a href="/home/">HOME</a></li>
<li class="active">ABOUT US</li>
<li><a href="/services/">SERVICES</a></li>
<li><a href="/partners/">PARTNERS</a></li>
<li><a href="/customers/">CUSTOMERS</a></li>
<li><a href="/projects/">PROJECTS</a></li>
<li><a href="/careers/">CAREERS</a></li>
<li><a href="/contact/">CONTACT</a></li>
</ul>
</nav>
Менюшку мы написали, прикрутим к ней классы.
nav a {
text-decoration: none;
}
nav ul {
margin: 0;
padding: 0;
}
nav li {
list-style-position: inside;
font: 14px 'Oswald', sans-serif;
padding: 10px;
}
.top-menu li {
display: inline-block;
padding: 10px 30px;
margin: 0;
}
.top-menu li.active {
background: #29c5e6;
color: #fff;
}
.top-menu a {
color: #b2b2b2;
}
Бэмер
Вы опираетесь на структуру и каскады — у вас все развалится при первой же правке. Правильней будет так:
HTML:
<div class="b-menu">
<a href="#" class='b-link b-link_menu b-link_menu_active' >HOME</a>
<a href="#" class='b-link b-link_menu' >ABOUT US</a>
<a href="#" class='b-link b-link_menu'>SERVICES</a>
<a href="#" class='b-link b-link_menu'>PARTNERS</a>
<a href="#" class='b-link b-link_menu'>CUSTOMERS</a>
<a href="#" class='b-link b-link_menu'>PROJECTS</a>
<a href="#" class='b-link b-link_menu'>CAREERS</a>
<a href="#" class='b-link b-link_menu'>CONTACT</a>
</div>
CSS:
.b-menu
{
margin:0;
padding:0;
list-style:none;
width:100%;
display:table;
table-layout: fixed;
}
.b-link_menu
{
text-align:center;
color:#bfbfbf;
cursor:pointer;
font-size:14px;
height:38px;
background-color:#f3f3f3;
line-height:38px;
border: 1px solid #e7e7e7;
display:table-cell;
text-decoration: none;
}
.b-link_menu_active
{
color:#fefefe;
background-color:#29c5e6;
border:1px solid #29c5e6;
}
При таком подходе вам ничего не стоит поменять структуру HTML, не развалив при этом стили.
Акт II: Недопонимание
Семантист
Какой смысл плодить кучу классов? Не проще и не короче ли тогда прописать инлайн стили? Зачем раздувать CSS файл? Ничего не понятно!
Бэмер
Классы максимально спецефичны и при обработке браузером, а проведенные исследования показывают, что это играет роль в современном мире будут отрабатываться быстрей. Инлайн стили размажутся по всему проекту и их поддержка будет максимально сложная. Лучше раздуть CSS файл, чем завалить верстку при внесении правок.
Семантист
Для меня важней семантика и наглядность как HTML, так и CSS, чем время отработки CSS-инструкций браузером, ведь код пишу я, а не браузер. Более того такое большое количество стилей легко забыть при написании HTML и их привязке к структуре проекта. Чтобы верстка не падала надо лучше думать над семантикой.
Акт III: Переход в другое измерение
Бэмер
Вы все еще пишите HTML руками? У нас ведь есть такие прекрасные элементы как bemhtml и bemjson — вы описываете классы (которые кстати говоря можно использовать многократно), их положение в структуре документа и наполнение, а тулзы за вас генерят HTML разметку, и раскладывают все по полочкам. Следовательно вам нет нужды касаться HTML напрямую.
Семантист
А зачем мне использовать какие-то тулзы? Я лучше воспользуюсь препроцессорами HTML и CSS — эффект будет тот же но кода меньше и все намного понятнее и нагляднее.
Акт IV: Развязка
Бэмер
Еще один «не въехал в БЭМ» и зачем-то приплел препроцессоры, и вообще сравнивает теплое с мягким, мы ведь предлагаем методологию, которая с успехом применяется на крупных проектах и все только за.
Семантист
Все равно не вижу никаких плюсов вашего подхода, все только усложняется и обрастает какими-то дополнительными тулзами! Мой подход лучше, так как я уже не первый год работаю и у меня ничего не валится.
* Многое из описание холивара нарочно утрировано, перефразированно, выдернуто из контекста и прочее для того, что бы подчеркнуть расхожесть взглядов с разных сторон.
«Проблемы БЭМ’а»
Смысл всего описанного выше холивара по сути заключается в аргументации сравнения «теплого с мягким», просто под «теплым» и «мягким» каждый разработчик также подразумевает разные абстракции. И в этом и заключается самая главная проблема БЭМ’а и не «въехавших» — авторы методологии слишком много смысла вложили в эти 3 буквы, из-за чего те кто не работал с методологией видят только её часть через «замочную скважину» своего опыта и мироздания. И для того, чтобы понять зачем вообще её придумали и в чём смысл от её применения надо перечитать кучу информации, выявить в ней причинно-следственные связи, вжиться в неё, и всё это только для того, чтобы понять «зачем?». Авторы сами вырывают куски своей методологии для аргументации и все эти разрозненные куски называют БЭМ.
С одной стороны БЭМ — это просто принципы именования классов. Сама идея «Блок Элемент Модификатор» выглядит достаточно логичной — все сущности описываем блоками .b-example и вложенными в них элементами .b-example__element, для определенных блоков и иэлементов применяем модификаторы .b-example__mod_val /.b-example__element__mod_val. И такой подход позволяет повысить наглядность классов и определять их принадлежность к блоку только по имени.
С другой стороны БЭМ — это принципы реализации независимых блоков. Отказ от каскадности классов, отказ от привязки к структуре документа, максимальная спецефичность имен классов — все это с целью привнесения безболезненности и легкости при постоянно возникающих правках, редизайнах и прочего.
И самое интересное, что чем далее развивает методология, тем больше смысла вкладывается в эти 3 буквы:
БЭМ — отказ от ручного подхода в создании структуры HTML. Описываем все используемые классы, на JSON (в данном случае на спецефичном BEMJSON) создаем структуру документа и взаимоотношения классов — специальный инструмент (bemhtml) генерирует соответствующий HTML — всё здорово и все счастливы.
БЭМ — возможность генерации JS для работы с ранее сгенерированным HTML. * По этому пункту ничего осмысленного сказать не могу, так как не раработал с ним, надеюсь знающие люди подскажут.
«Корень зла»
На мой, сугубо личный взгляд, подобная переосмысленность 3 букв и является «корнем зла», не способствующим вовлечению широких масс в идеологию. Каждый раз, натыкаясь на недопонимание, авторам и идеологам приходится объяснять что именно они имеют ввиду в конкретном контексте под аббревиатурой БЭМ, и очень часто не удается толком это объяснить.
На все эти мысли меня, по факту, натолкнул один из коментариев с ссылкой на АНБ. И мне совершенно непонятно зачем нужно было уходить от такого, крайне понятного термина, как «Абсолютно независимый блок» или «Неискажающий блок», вводя дополнительную абстракцию «Блок Элемент Модификатор», которую каждый раз приходится объяснять и разжевывать.
Логичным решением возникшей проблемы, как мне кажется, является декомпозия столь глобальной абстракции на более мелкие, с последовательным введением терминологии для каждой более мелкой абстракции («сферы БЭМ’а»), что, кстати говоря, будет также отражать идеологию БЭМ’а — независимость использования и доработки каждой из абстракций.
Вместо заключения.
Лично для себя я определился с БЭМ:
- смысл от использования независимых блоков есть, и конечно же я буду их применять;
- правила именования классов мне не особо понравился — зачастую слишком избыточно (не буду спорить, что в крупных проектах это может быть панацеей), возможно буду использовать несколько модифицированный подход;
- инструменты БЭМ’а мне кажутся избыточными, по крайней мере для моих текущих задач, возможно в будущем рассмотрю их более подробно
