CSS Bliss: основные особенности методологии

Среди множества методологий организации стилей (BEM, SMACSS, OOCSS, SUITECSS) хочется отдельно выделить одну: CSS Bliss. Это квинтэссенция удобства использования и читабельности.

Для начала определимся в основных понятиях: модуль, элемент и модификатор. Эти определения наиболее близки БЭМу, за исключением того, что Модулем в CSS Bliss именуется Блок. Далее будет понятно, почему Модуль - более подходящее значение. В целом сама методология очень близка к БЭМу, но имеет свои особенности, о которых стоит поговорить отдельно, потому что именно они позволяют стать CSS Bliss на ступеньку выше остальных.



Основные отличия CSS Bliss:

1. Именование модуля, элементов и модификаторов:

Если в БЭМе основными разделительными частицами выступают "-" и "_":

.my-module__my-element_modifier

то CSS Bliss улучшает читабельность путем использования заглавных букв:

.MyModule-myElement--modifier

Лично мне очень сложно различать дефис и нижнее подчеркивание, тем более если они выглядят почти одинаково, отличаясь лишь парой пикселей смещения вниз. Тогда как заглавные буквы расставляют акценты и выделяют в словах то, что должно быть одним названием.

Возможно, на абстрактном примере это плохо видно, возьмем пример более приближенный к реальному проекту. Сравните:

<li class="custom-user-menu__list-item_size-normal"></li>

<li class="CustomUserMenu-listItem--sizeNormal"></li>

Первый БЭМовский вариант длиннее и сложнее в прочтении. Особенно сливается модификатор с названием элемента. Второй (CSS Bliss) более компактен и визуально разделен на понятные компоненты: модуль, элемент и модификатор. При чем отличие в первой букве моментально дает понимание что перед нами: модуль или элемент (модуль начинается с заглавной, а элемент - со строчной).

Если я вас еще не убедила, вот еще один пример из документации БЭМа для модификаторов "ключ - значение":

.block-name__elem-name_mod-name_mod-val

Сложно представить ситуацию, где бы пригодились подобные нечитабельные конструкции. На мой взгляд правильнее было бы использовать либо другое наименование, либо продумать другой способ разбирения на элементы и модификаторы.

2. Позиционирование компонентов.

Модуль независим и самодостаточен сам по себе. Он должен выглядеть одинаково в любом месте и при любом разрешении, именно поэтому он имеет одно важное ограничение: модуль не должен содержать в себе свойства, которые бы жестко задавали его позиционирование, а именно: размеры (width), внешние отступы (margin) и позиционирование по отношение к другим элементам (position). Эти свойства должны задаваться либо в модификаторе модуля либо этот модуль так же является элементом внешнего блока, который (элемент) и определяет его положение.

Это очень важное отличие делает модули действительно независимыми ни от месторазмещения модуля на странице, ни от размеров экрана. Их легко переиспользовать.

3. Организация структуры

Несмотря на удобство организации файловой структуры в БЭМе, он предполагает излишне дробное деление: каждый модификатор и элемент выносится в отдельный файл. Пример:

blocks
├─── popup
|    ├──── _target
|    |    ├──── popup_target.css
|    |    ├──── popup_target_anchor.css
|    |    └──── popup_target_position.css
|    └──── _visible
|         ├──── popup_visible.css
|         ├──── popup.css
|         └──── popup.js

Тогда как в CSS Bliss предполагает создавать файлы только для модулей, а его внутренние элементы и модификаторы описывать внутри этого же файла, так как вне его они не имеют смысла:

css
├─── modules
|    ├──── _PopupDialog.scss
|    ├──── _Btn.scss
|    └──── _ElmInfo.scss
├─── _base.scss
├─── _colors.scss
├─── _mixins.scss
├─── _zindex.scss
└─── application.scss

При этом можно создавать общие файлы для всего проекта, что тоже очень удобно.

4. Состояние элемента: state

Очень часто нам нужно определять состояние элемента или модуля: активный, скрытый, доступный, использованный и проч. Использование для этого модификатора не только загромождает читаемость html, но и загрязняет javascript.

Пример на БЭМе:

<div class="my-module__my-mlement my-module__my-mlement_my-modifier-with-state"></div>

Пример на Bliss CSS:

<div class="MyModule-myElement isState"></div>

В последнем примере мы используем для изменения состояния в js не длиное название модификатора: "my-module__my-mlement_my-modifier-with-state", а привычное и универсальное "isState". Из-за того, что состояние определяется только для конкретного модуля или элемента, оно обладает локальным воздействием на него. А универсальное наименование состояния позволяет при необходимости переиспользовать js-код для различных элементов страницы.

5. Использование @extend

Лично я - противник использования такой возможности sass как расширение классов с помощью @extend. Главные требования к CSS должны быть:

• простота
• читабельность
• легкоизменяемость

С помощью @extend вы расширяете исходные классы дополнительным кодом, при чем из любого другого места. Несмотря на кажущуюся простоту концепции, @extend в корне противоречит отновному принципу каскадности стилей; им сложно управлять и читать. Неудивительно, что Bliss CSS запрещает использование @extend для классов и элементов.

6. Документация

Помимо обычной документации на сайте описании CSS Bliss, для разработчиков существует интерактивная документация в примерах, где можно не только проверить свои знания в правильном понимании методологии, но и на конкретных примерах разобраться как с помощью CSS Bliss лучше решать те или иные задачи.

Это лучшая прикладная документация, которую я встречала.

Выводы

Несмотря на большую популярность БЭМа в последнее время, CSS Bliss по всем вышеуказанным причинам гораздо практичнее. И как и прочие методологии она вырабатывает привычку думать не в разрезе страницы, а в терминах компонентов: модули, элементы, модификаторы; что делает процесс написания css'a более осознанным, так как от привильного разбиения на компоненты зависит не только красота кода, но и жизнеспособность стилей в будущем.