Frontender Magazine

Что такое CSS-модули и зачем они нам?

В последнее время меня интригуют CSS-модули. Если вы о них не слышали — эта статья для вас. Мы рассмотрим, что это за проект, какие задачи он решает и каковы причины его возникновения. Если вы тоже заинтриговались — не переключайтесь, следующая статья будет о том, как начать их применять. А если вас интересует внедрение в проект или более продвинутое использование CSS-модулей, третья статья в этой серии будет о том, как использовать их c React.

Серия статей

Часть 1: Что такое CSS-модули и зачем они нам? (Вы её читаете!)

Часть 2: Начинаем использовать CSS Modules

Часть 3: React + CSS Modules = 😍 (Скоро!)

Что такое CSS-модули?

Согласно определению из репозитория, CSS-модули — это:

CSS-файлы, в которых все классы и анимации по умолчанию находятся в локальной области видимости.

CSS-модули — это не официальная спецификация, они не имплементированы в браузеры, скорее, это задача, запускаемая на стадии сборки проекта (например, с помощью Webpack или Browserify), в процессе выполнения которой имена классов и селекторы изменяются так, чтобы образовалась своего рода локальная область видимости (что-то вроде пространства имен).

Как это выглядит и зачем нам это? Сейчас расскажу. Во-первых, вспомните как обычно работают HTML и CSS. Класс прописывается в HTML:

<h1 class="title">Пример заголовка</h1>

И стилизуется в CSS:

.title {
  background-color: red;
}

Пока CSS применяется к HTML-документу, фон <h1> будет красным. Нам не нужно как-то обрабатывать CSS или HTML, оба формата понятны браузеру.

CSS-модули используют другой подход. Вместо того, чтобы писать обычный HTML, нам придётся написать разметку в JavaScript-файле, например, в index.js. Вот как это может выглядеть (ниже мы рассмотрим более реальные примеры):

import styles from "./styles.css";

element.innerHTML = 
  `<h1 class="${styles.title}">
     Пример заголовка
   </h1>`;

В процессе сборки компилятор проанализирует styles.css, который мы импортировали, потом проанализирует JavaScript и сделает класс .title доступным через styles.title. Затем сгенерирует на их основе новые HTML и CSS-файлы, уже с новыми классами.

Сгенерированный HTML может выглядеть следующим образом:

<h1 class="_styles__title_309571057">
  Пример заголовка
</h1>

А вот так может выглядеть CSS:

._styles__title_309571057 {
  background-color: red;
}

Скриншот

Значение атрибута class и селектор .title заменены на новые. Исходный CSS в браузер вообще не попадает.

Как сказал Хьюго Жироде́ль (Hugo Giraduel) в своей статье по этому поводу:

[классы] генерируются автоматически, они уникальны и привязанны к исходным стилям.

Вот это и называется поместить стили в локальную область видимости. Они находятся в области видимости определенного шаблона. Если у нас есть файл buttons.css, он будет импортирован только в шаблон buttons.js, и класс .btn, который он содержит, будет недоступен для других шаблонов (например, forms.js), пока мы не импортируем его и туда тоже.

Зачем нам устраивать всю эту канитель с CSS и HTML? Зачем нам это вообще сдалось, ради всего святого?!

Зачем нам нужно использовать CSS-модули?

CSS-модули гарантируют, что все стили одного компонента:

  1. Находятся в одном месте
  2. Применяются только к этому компоненту и никакому другому

Кроме того, каждый компонент может иметь настоящие зависимости, например:

import buttons from "./buttons.css";
import padding from "./padding.css";

element.innerHTML = `<div class="${buttons.red} ${padding.large}">`;

Этот подход был разработан, что бы решить проблему глобальной области видимости в CSS

Вы когда-нибудь испытывали соблазн в условиях нехватки времени или ресурсов просто писать CSS так быстро, как можете, не думая о последствиях?

Пихали ли в конец таблицы стилей какой-нибудь мусор, собираясь потом его отрефакторить, и так никогда этого и не сделали?

Бывало ли такое, что вы просматривали стили, не до конца понимая что они делают и используются ли они вообще?

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

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

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

Например, если вы используете в HTML класс random-gross-class, не обработав его как класс CSS-модуля, стили не применятся, так как CSS-селектор превратится во что-то вроде ._style_random-gross-class_0038089.

Ключевое слово composes

Допустим, у нас есть модуль под названием type.css, содержащий стили для текста. В этом файле может быть, например, такое:

.serif-font {
  font-family: Georgia, serif;
}

.display {
  composes: serif-font;
  font-size: 30px;
  line-height: 35px;
}

Один из этих классов мы используем в шаблоне:

import type from "./type.css";

element.innerHTML = 
  `<h1 class="${type.display}">
    Пример заголовка
  </h1>`;

В результате получится такая разметка:

<h1 class="_type__display_0980340 _type__serif_404840">
  Пример заголовка
</h1>

Оба класса связаны с элементом через использование ключевого слова composes, решая таким образом некоторые проблемы, которые есть в похожих решениях, например в @extend Sass.

Так можно даже подставлять данные из отдельного CSS-файла:

.element {
  composes: dark-red from "./colors.css";
  font-size: 30px;
  line-height: 1.2;
}

БЭМ не нужен

Нам не нужен БЭМ, если мы используем CSS-модули. По двум причинам:

  1. Простота чтения. Код вроде type.display так же понятен для разработчика, как и .font-size__serif--large из БЭМ. Его даже проще читать, чем разросшиеся БЭМ-селекторы.

  2. Локальная область видимости. Допустим, в одном из модулей у нас есть класс .big и он увеличивает font-size на некоторую величину. В другом модуле у нас есть точно такой же класс .big, который увеличивает padding и font-size на другую величину. И это не имеет никакого значения! Они не будут конфликтовать, так как у стилей различаются области видимости. Даже если модуль импортирует обе таблицы стилей, у классов будет своё уникальное имя, созданное в процессе сборки специально для них.

    Другими словами, при использовании CSS-модулей проблемы специфичности селекторов просто исчезают.

Круто, да?

И это только некоторые из достоинств использования CSS-модулей.

Если вам интересно узнать больше, Глен Маден (Glen Madden) много пишет на эту тему.

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

Материалы для дальнейшего изучения

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Robin Rendle
Автор:
Robin Rendle
GitHub:
robinrendle
Twitter:
@robinrendle
Сaйт:
https://robinrendle.com/
Антон Немцев
Переводчик:
Антон Немцев
Сaйт:
http://frontender.info/
Twitter:
@silentimp
GitHub:
SilentImp
Skype:
ravencry

Комментарии (14 комментариев, если быть точным)

Автар пользователя
rbelmega

angular2 rocks! it works well with it

Автар пользователя
GM2mars

Какая-то бесполезная шляпа. Если мы хотим соблюдать область видимости в css достаточно использовать составные классы типа .menu .menu-links .menu-block и так далее (ну или просто использовать бэм). По моему некоторые разработчики уже просто не знают чем заняться и выдумывают всякую ерунду. Тем более css модули не решают никакую проблему (кроме надуманных). Для удобной классификации элементов достаточно использовать любой препроцессор и все будет на своих местах.

Автар пользователя
iamstarkov

@GM2mars 15295904-9be6-4291-8a8f-7e105453cd6c

Автар пользователя
olegreznichenko

<style scoped>

Автар пользователя
SilentImp

@GM2mars нет, не достаточно. Никакой БЭМ не обеспечит изоляцию стилей.

@Nonlimit Поддержка на данный момент только в FF и то, кажется, с оговорками.

Автар пользователя
radist2s

Было бы интересно понять, как это можно использовать, например, с php-файлами. А так же было бы круто, если бы IDE делала авоткомплит для такого рода штук:

${styles.title}

Автар пользователя
dzhiriki

@radist2s postcss-modules создает JSON с маппингом имен для каждого файла стилей. А JSON можно читать уже на любом бекенде.

Автар пользователя
kattiperk

Кажется, изначально подразумевалось, что модули будуь независимыми по стилям. Но теперь засунули в js и сделали нечитаемые классы. Хотя используя подход CSS модулей легко создать свои и переиспользовать их без вреда для макета.

Автар пользователя
virtyaluk

@Nonlimit, неделю-две назад была статья о том, что "style scoped" помечен как deprecated в официальной спецификации в силу того, что только FF его поддерживает.

Автар пользователя
virtyaluk

Соглашусь с оратором выше, эти CSS-модули - бестолковый самопал, который добавляет больше проблем, чем решает. И пол беды если бы этот проект имел шансы стать частью официальной спецификации и получить нормальную поддержку в браузерах, а так, в силу своей "дырявости", бьюсь об заклад, этого никогда не случится. Разработчиков только недавно начали отучивать от мешанины разметки, стилей и кода, а здесь опять предлагают "вшивать" стили в код. Зачем? Почему то вспомнил WebComponents и Polymer, которые так и заглохли в силу несовершенности технологии и слабого желания производителей браузеров делать поддержку таких рисковых технологий. Гугл даже решили повременить с захватом мира Полимером.

Автар пользователя
coderlex

.font-size__serif--large - ни разу не БЭМ, а говнокод.

Автар пользователя
iamstarkov

@coderlex умерьте пыл, это другая нотация, но всё ещё бэм

Автар пользователя
coderlex

@iamstarkov я не про нотацию, сам такой пользуюсь. Обратите внимательнее на название блока. Вероятно подразумевается его использование в качестве миксина, но родительского блока font-size в реальности нет. Также как и элемента serif. Это противоречит идеологии БЭМ само по себе. Строго говоря этот код вообще не БЭМ, а просто что-то визуально похожее.

Но даже если выкинуть из головы идеологию БЭМ есть ошибка более низкого уровня - нарушение семантичности. Класс типа font-size__serif--large по сути ничем не отличаются от какого-нибудь margin__bottom--large. Всё это - смешивание разметки и стилей.

Если хочется вынести общие настройки в какое-то определенное место, то это реализуется не так, а переменной SASS/LESS:

.modal { ... &__title { font-family: $font-family-serif; font-size: $font-size-large; } }

Автар пользователя
PeterMikhaylov

ну зато можно называть вещи своими именами и наконец избавиться от бесполезных префиксов в класснеймах типа btn__) В каждом файлике стилей писать просто .disable {...} .large {...} и не беспокоиться о том, что они перекроют другие стили или заматчатся на другие стили