Page Content
Строго говоря, вопрос длинных классов актуален не только для БЭМ. Просто для БЭМ, данный вопрос актуален особенно. К тому же, я ярый сторонник семантики в HTML-разметке. И наличие семантичных классов вида my-super-puper-duper-class, считаю, стало уже давно архаизмом. Вот и решился сделать CSS-классы по БЭМ короче, сильно короче, а именно, из двух символов. Что ж, сказано — сделано.
Публикация от . Крайнее обновление .
Зачем это нужно?
Вопрос справедливый. Попробую на него ответить от обратного. Зачем на клиенте нужны полноразмерные БЭМ-классы? Есть ли этому какое-либо разумное объяснение? ИМХО, полноразмерные/исходные классы разработчиков на «боевом» сайте не нужны. А раз не нужны, так давайте извлечем из этого пользу. А именно, уменьшим вес страницы и, тем самым, ускорим загрузку. Бонусом мы защитим код от копи-пасты.
Реализация
Да что тут реализовывать?! — скажете вы, и будете правы. Получаем список простых селекторов из файлов со стилями, проходимся циклом по шаблонам и стилям, где меняем «старые» классы на «новые» классы. Вот, собственно, и всё.
Я же хочу поделиться одним интересным моментом из всего этого процесса, а именно, хочу поделиться размышлениями на тему «какими классами будем менять одни на другие».
Менять на односимвольные нельзя, ибо имя класса должно начинаться именно с буквы, и взможных классов будет мало, всего 26. Да и хотим-то мы именно двух-символьные классы. А вот если будем использовать два символа, то получим 26*26 = 676, как-то невнятно, сразу и не скажешь хватит или нет. Вспомним про арабские цифры и получим уже 36*36 = 1296 возможных комбинаций.
Внимательный читатель заметит, что получили мы ни что иное, как 36-тиричную систему счисления.
Отбросим первые 360 чисел, которые начинаются с арабских цифр или имеют всего один разряд. В итоге остаётся 36*36 - 360 = 936 двухсимвольных классов — этого уже достаточно для обычного сайта.
Если ваш проект достаточно «бородат», используйте три символа, которые дадут вам уже десятки тысяч трёхсимвольных классов, а точнее, 36*36*36 - 12960 = 33696. Этого уже более чем достаточно, для проекта над которым работают не люди-снежинки.
Результат
Код страницы стал выглядеть примерно так:
<body class="ic">
<div class="ik">…</div>
<nav class="jg">…</nav>
<div class="j6">
<header class="b6 ff">…</header>
<div class="eo">
<section class="ep av">…</section>
<section class="ep ci">…</section>
<section class="ep a2">…</section>
</div>
</div>
</body>
А стили так:
.h7 .ii { … }
.hy, .eb { … }
.cb:not(.gu) { … }
Немного статистики: 41223 — количество символов на главной странице до минификации, 30926 — после минификации.
Таким образом мы уменьшили код страницы на 25%, сохранив прежнюю фунцкиональность.
В целом, стили и разметка таким образом «жмутся» примерно на 25%. Довольно неплохой результат. Опережая возгласы «Есть же gzip, который уже включает в себя схожие алгоритмы!», скажу, что одно другому не помеха. Если вопрос касается оптимизации, то нельзя останавливаться на полпути, всегда есть что, где и куда ужать.
Замеры сетевых и клиентских метрик оставим критикам. Для нас же важен сам факт — при минимальных затратах, сохранив функционал, мы сделали наш код чище и оптимальнее.
А стоит ли?
Стоит отметить, что на habrahabr.ru была статья на аналогичную тему. Данный вопрос имел активное обсуждение, в котором бОльшая часть читателей выразилась резко против данного подхода, по причинам: отсутствующего или малозаметного выигрыша в весе, наличия сложностей в отладке и сборке.
И да, заведите перечень исключений из классов, которые должны иметь стандартизованное имя, например, fn, и классов, которые меняются «на лету», если таковые имеются.