Утилитарные CSS-классы: Tailwind и обычный CSS

Tailwind CSS сломал привычную модель «пиши семантические классы и опиши их в CSS». Вместо .card { padding… } вы пишете class="p-4 rounded-lg shadow". Это другой способ думать о вёрстке — и у него есть цена, которую не видно на демо. Разберём, что такое утилитарные классы, чем они не похожи на обычный CSS/SCSS и когда между ними нужен мост.

Две модели именования

Классическая (семантическая): класс описывает что это, а сами стили живут в отдельном CSS-файле.

.card { padding: 1rem; border-radius: 0.5rem; box-shadow: 0 4px 6px rgba(0,0,0,.1); }

.card { padding: 1rem; border-radius: 0.5rem; box-shadow: 0 4px 6px rgba(0,0,0,.1); }

<div class="card">…</div>

<div class="card">…</div>

Утилитарная (Tailwind): класс описывает как выглядит и стоит прямо в разметке; CSS-файл — это собранный из утилит набор.

<div class="p-4 rounded-lg shadow">…</div>

<div class="p-4 rounded-lg shadow">…</div>

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

Чем хорош Tailwind

• Скорость без «что уже есть в проекте». Не надо гуглить, существует ли класс .card и что он делает: p-4 всегда означает padding: 1rem.
• Локальность. Меняете карточку — правите разметку этой карточки, а не общий CSS, от которого боитесь задеть пять других мест.
• Дизайн-токены как ограничения. Палитра, отступы, размеры шрифта заданы сеткой — верстка получается консистентной «по умолчанию», не «если дизайнер проследил».
• Responsive/состояния без медиа-запросов руками: md:p-6, hover:shadow-lg, focus:outline-none.

Чем плох Tailwind (и почему это не бесплатно)

• Разметка шумит. Много классов на элементе — тяжело читать и тяжело диффать в ревью.
• Привязка к билду. Нужен PostCSS-конвейер и сканирование исходников; «включил <link> и работает», как с обычным CSS, не будет.
• Локдаун на экосистему. Переносить проект на другой стек или отдавать CSS клиенту с требованием «обычный CSS без сборки» — боль.
• Специфичность и !important. Перебить утилиту сложнее, чем семантический класс; отсюда разрастание модификаторов.
• Классы не объясняют «зачем». p-4 не скажет, что это «отступ карточки». Через полгода по разметке не поймёшь дизайн-смысл.

Роль SCSS здесь

SCSS/sass — не отдельная философия, а надстройка над обычным CSS: переменные, вложенность, @mixin, @extend. p-4→padding:1rem из Tailwind в SCSS легко записать как миксин, который вызывается внутри семантического класса:

$radius-lg: .5rem;
@mixin card { padding: 1rem; border-radius: $radius-lg; }
.card { @include card; }

$radius-lg: .5rem;
@mixin card { padding: 1rem; border-radius: $radius-lg; }
.card { @include card; }

<div class="card">…</div>

<div class="card">…</div>

То есть SCSS возвращает «оформление в файл, структура в разметку», но с выразительными средствами. Это чаще и просят там, где Tailwind запрещён политикой сборки.

Карта соответствия: как Tailwind переводится в CSS

Важный нюанс: утилита часто несколько свойств сразу (text-sm — и размер, и интерлиньяж). Механический перевод «1 класс = 1 свойство» даёт неверный CSS. Хороший конвертер знает эту карту.

Когда нужен перенос между стилями

1. Забираете дизайн из Tailwind-макета в проект без сборки (WordPress-тема с обычным CSS, письмо, встроенные стили) → нужен Tailwind → CSS.
2. Хотите рефакторить Tailwind-разметку в семантические классы и держите стили в SCSS → Tailwind → SCSS (с вложенностью/переменными).
3. Наоборот, пересаживаетесь на Tailwind и хотите превратить готовый CSS-файл в набор утилит в разметке → CSS → Tailwind.

При переносе теряются: responsive-префиксы (их надо заново навесить брейкпоинтами), состояния hover/focus (в обычном CSS это псевдоклассы), произвольные значения w-[17px] (это literal-CSS, не токен).

Прогоняем маппинг без ручной сверки

Держать всю таблицу соответствий в голове и глазами разворачивать text-sm в два свойства — та ещё рутина. В codestack.space для этого есть AI Tailwind Converter. Он переводит в обе стороны и попутно раскладывает утилиты так, как их положено:

• Tailwind → CSS и Tailwind → SCSS (с переменными/вложенностью), CSS → Tailwind;
• флаги: комментарии с исходными классами (чтобы в CSS видеть, из какой утилиты что выросло), mobile-first (медиа-запросы в правильную сторону), вынести значения в переменные (токены вместо магических чисел).

Классы берутся из реальной утилитной сетки, поэтому md:/hover: не теряются, а превращаются в медиа-запрос и псевдокласс. Попробуйте инструмент прямо здесь, на своих данных:

Сам перенос тривиален — непросто понять, где у вас кончается Tailwind и начинается «обычный CSS для клиента». Зная разницу между двумя моделями выше, вы просто перестаёте вручную раскладывать rounded-lg и не теряете hover:opacity-0 по дороге.