Двухсимвольные классы

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⁠, и классов⁠, которые меняются «⁠на лету⁠», если таковые имеются⁠.