Вроде неделя из 30 строчек кода закончилась и видимо неделя пришла взамен" БЭМ При этом есть довольно забавная последовательность тем:
- Создаем веб-страницу за 15 минут.
- Было бы лучше на BЭM'e!
- Ты ешь свой бэм, у меня есть препроцессоры!
Но почему? Почему одни люди твердо верят в методологию БЭМ, а другие презирают ее как узурпатора семантики? Попробую высказать свою точку зрения на суть всего холивара и, прежде всего, прояснить для себя положение БЭМ в моей собственной вселенной.
На самом деле БЭМ я заинтересовался уже давно, идея мне понравилась, я пытался в нее вникать, пытался применить ее на практике, но как-то не получалось, не знаю почему.
Я сделал несколько подходов, но в итоге мой проект превратился в жуткую мешанину попыток реализовать BЭM и «идей кристально-семантического HTML+CSS» (на которые я перешёл, разочаровавшись в BЭM).
На самом деле меня это радует, до сих пор печалит и приносит ежедневную радость от боли работы над проектом.
Попавшиеся статьи из ката и комментарии к ним вызвали у меня бурю эмоций по вопросам семантики верстки, браузерных устройств, БЭМ, препроцессоров и всего, что так или иначе связано с темой идеологий.
, методологии, методики и прочее.
Поскольку мой личный подход к использованию БЭМ не увенчался успехом, но в голове все еще бродили вполне логичные обоснования использования методики, то в каждой статье и каждом комментарии я старался найти истину, которая хоть как-то ответила бы на мои вопросы и наконец, сформировал бы мое личное отношение к BЭM. Как ни странно, это произошло в один момент. Как это произошло и почему я постараюсь вам донести.
Рассмотрим типичный холивар
Персонажи
Семантик – это человек, отрицающий БЭМ.
Бэмер - последователь BЭM.
Акт 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ЭM — это просто принципы именования классов.
Сама идея «Модификатора BlockЭElement» выглядит вполне логичной — мы описываем все сущности с блоками .
b-example и вложенными в них элементами .
b-example__element, для определенных блоков и элементов мы используем модификаторы .
b-example__mod_val/ .
b-example__element__mod_val. И такой подход позволяет повысить видимость классов и определять их принадлежность к блоку только по имени.
С другой стороны, BЭM — это принципы реализации независимых блоков.
Отказ от каскадирования классов, отказ от привязки к структуре документа, максимальная специфичность названий классов — все это с целью сделать безболезненными и легкими постоянно возникающие правки, редизайны и прочее.
И самое интересное, что чем дальше развивается методика, тем больше смысла вкладывается в эти 3 буквы: БЭМ — отказ от ручного подхода к созданию HTML-структуры.
Описываем все используемые классы, создаём структуру документа и отношения классов с помощью JSON (в данном случае конкретного BEMJSON) — специальный инструмент (bemhtml) генерирует соответствующий HTML — всё отлично и все довольны.
БЭМ — возможность генерировать JS для работы с ранее сгенерированным HTML. * Ничего толкового по этому поводу сказать не могу, так как не работал с этим, надеюсь знающие люди подскажут.
«Корень зла»
По моему сугубо личному мнению, такое переосмысление 3-х букв является «корнем зла», не способствующим вовлечению широких масс в идеологию.Каждый раз, сталкиваясь с непониманием, авторам и идеологам приходится объяснять, что именно они подразумевают в конкретном контексте под аббревиатурой БЭМ, и очень часто им не удается это объяснить должным образом.
На самом деле все эти мысли натолкнул один из комментариев со ссылкой на АНБ .
И мне совершенно непонятно, почему понадобилось отходить от такого предельно ясного термина, как «Абсолютно независимый блок» или «Неискажающий блок», вводя дополнительную абстракцию «Модификатор блочного элемента», которую приходится объяснять и жевал каждый раз.
Логичным решением возникшей проблемы, мне кажется, является разложение такой глобальной абстракции на более мелкие, с последовательным введением терминологии для каждой меньшей абстракции («сферы БЭМ»), что, по Кстати, также будет отражаться идеология BЭM'a - независимость использования и модификации каждой из абстракций.
Вместо заключения.
Лично я остановил свой выбор на BЭM:
- Есть смысл использовать независимые блоки, и я их, конечно, буду использовать;
- Правила именования классов мне не особо понравились — они зачастую слишком избыточны (не буду утверждать, что в больших проектах это может быть панацеей), возможно, я воспользуюсь несколько модифицированным подходом;
- Инструменты БЭМ мне кажутся избыточными, по крайней мере для моих текущих задач, возможно в будущем я рассмотрю их более подробно
-
Microsoft Собирается Покинуть Китай
19 Oct, 24 -
Почему Я Больше Не Пытаюсь «Войти В It»?
19 Oct, 24 -
Мебель Для Ноутбука
19 Oct, 24
