Как связать типографические токены с темами и цветовыми режимами

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

Дата актуальности: 22 июля 2026 года.

Типографические токены — это именованные значения, которые описывают текст в интерфейсе: семейство шрифта, размер, насыщенность, межстрочный интервал, трекинг и иногда дополнительные параметры вариативного шрифта. Вместо разрозненных значений вроде 16px или font-weight: 600 команда работает с понятными ролями: body-md, heading-lg, label-sm или display-xl.

Токен отличается от обычного значения тем, что получает смысл и может использоваться повторно. Если размер основного текста меняется с 16 до 17 пикселей, достаточно изменить базовый токен или связь семантического токена с базовым. Компоненты не приходится редактировать по отдельности, поэтому типографика становится управляемой частью дизайн-системы.

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

Разделение важно и для нескольких брендов. Одна и та же типографическая модель может работать с разными палитрами, если шрифтовые роли не зашиты в конкретные цвета. И наоборот, одна цветовая система может использовать разные шрифты для веб-сайта, мобильного приложения и административной панели без копирования всей архитектуры токенов.

Надёжная система обычно строится в несколько уровней. Базовые токены содержат исходные значения, типографические объединяют параметры текста в стили, а семантические связывают эти стили с задачами интерфейса. Такое разделение позволяет менять тему, бренд или масштаб интерфейса без потери логики компонентов.

Например, базовый токен font-size-400 может хранить значение 16px, а типографический body-md — ссылаться на него вместе с line-height-400, font-weight-400 и letter-spacing-normal. Компонент не обязан знать эти исходные значения: он получает роль body-md и применяет её в нужном контексте.

Начинайте не с названий HTML-тегов, а с визуальных задач. Заголовок карточки и заголовок страницы могут использовать разные размеры, хотя оба технически являются заголовками. Название роли должно описывать назначение и масштаб, а не конкретный элемент: heading-page, heading-section и heading-card устойчивее, чем h1, h2 и h3.

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

Связь с темой появляется на семантическом уровне. Токен body-md описывает параметры набора, а content-primary описывает цвет основного текста. Компонент получает оба значения: типографическую роль для формы текста и цветовую роль для контраста. В светлой теме content-primary может быть тёмным нейтральным цветом, в тёмной — светлым нейтральным цветом.

Не стоит создавать отдельный набор body-md-light и body-md-dark, если меняется только цвет. Такие названия смешивают две независимые характеристики и быстро приводят к дублированию. Исключение возможно, когда в разных режимах действительно меняются параметры шрифта: например, из-за особенностей начертания, оптического размера или требований к плотности текста.

Для каждого режима определите не только пару background и text, но и набор поверхностей и состояний. Текст на основном фоне, текст на карточке и текст на акцентной кнопке могут иметь разные требования к контрасту. Поэтому семантические роли должны ссылаться на цвета режима, а не на универсальные значения вроде black или white.

Пример логики может выглядеть так: body-md использует шрифтовые параметры, content-primary использует цвет текста текущей темы, а button-label применяет body-sm с повышенной насыщенностью и ролью content-on-accent. При переключении режима меняются ссылки цветовых ролей, но сам button-label сохраняет размер, высоту строки и вес.

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

В CSS базовые и семантические значения можно представить пользовательскими свойствами. Названия должны быть единообразными и отражать слой архитектуры. Например, типографический токен --type-body-md отвечает за набор параметров, а --color-content-primary — за цвет. В компоненте эти роли объединяются, но не подменяют друг друга.

Для светлой темы --color-content-primary может ссылаться на тёмный нейтральный цвет, а для тёмной темы — на светлый. При этом --type-body-md остаётся общим. Если дизайн требует отдельной настройки для тёмного режима, её следует оформить как осознанное переопределение, а не как копию всей типографической системы.

Соберите все существующие текстовые стили из макетов и продукта: заголовки, абзацы, кнопки, поля форм, подписи, таблицы, подсказки и сообщения об ошибках. Зафиксируйте размер, вес, высоту строки, цвет и контекст поверхности. Инвентаризация показывает, какие значения повторяются, а какие являются разовыми исключениями.

Перенесите повторяющиеся параметры в базовый слой, затем создайте типографические стили и семантические цвета. Не называйте токены по оттенку или компоненту, если они выражают более широкую роль. Название neutral-700 описывает палитру, а content-secondary — назначение; второе имя лучше подходит для смены темы.

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

Проверяйте текст на каждой поверхности, включая hover, focus, active, visited, error и disabled. Особое внимание уделите вторичному тексту и тонким начертаниям: визуально спокойный стиль не должен превращаться в потерю информации. Для интерактивных элементов дополнительно проверяйте заметность фокуса с клавиатуры.

Документация должна объяснять, какой токен выбирать для конкретного сценария. Укажите допустимые роли, примеры сочетаний и случаи, когда исключение оправдано. Без таких правил команда начнёт создавать локальные значения, и через несколько итераций связь между темой, типографикой и компонентами ослабеет.

Представим карточку статьи. Заголовок использует heading-card, описание — body-sm, дата публикации — caption. Цвет заголовка задан ролью content-primary, описание получает content-secondary, дата — content-muted. Кнопка внутри карточки использует label-md и content-on-accent на фоне action-primary.

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

Если заголовок на акцентной обложке требует другого цвета, не меняйте content-primary глобально. Создайте роль content-on-hero или content-on-accent и применяйте её только на соответствующей поверхности. Такой подход предотвращает побочные эффекты, когда изменение одного контекста неожиданно ухудшает читаемость обычных карточек.

Первая ошибка — создавать отдельные токены для каждой темы без необходимости. Наборы вроде light-heading-card и dark-heading-card быстро дублируют параметры и затрудняют изменения. Если режимы различаются только цветами, разделяйте цветовые и типографические слои.

Вторая ошибка — называть семантические роли по цветам: gray-text, white-text или blue-link. При смене палитры такие имена становятся ложными и провоцируют неправильное использование. Третья ошибка — использовать muted для обязательной информации. Вторичный цвет должен снижать акцент, но не скрывать содержание и не ухудшать доступность.

Четвёртая ошибка — связывать типографические токены только с HTML-уровнями. Один и тот же h2 может быть заголовком секции, карточки или боковой панели, поэтому визуальная роль не всегда совпадает с семантическим тегом. Пятая ошибка — тестировать только обычное состояние и забывать о фокусе, ошибках, инверсных поверхностях и пользовательском масштабировании.

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

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

Используйте имя, описывающее контекст поверхности: content-on-accent, content-on-hero или content-on-inverse. Такое название не зависит от конкретного оттенка и сразу объясняет, где применять токен. Для нескольких акцентных поверхностей создавайте отдельные роли только при различиях в контрасте или визуальной функции.

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

Разделите брендовые токены семейства шрифта и функциональные типографические роли. Тема или бренд может заменить font-family, но body-md, heading-page и label-sm должны сохранять назначение. После замены обязательно проверьте ширину строк, переносы, высоту блоков и наличие нужных кириллических начертаний.

Система перегружена, если команда не может быстро выбрать роль по документации, а одинаковые стили отличаются одним малозаметным параметром. Объединяйте токены с одинаковой функцией, удаляйте неиспользуемые значения и оставляйте исключения только для подтверждённых сценариев. Простая шкала лучше полного каталога разовых вариантов.

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

Если вы выстраиваете собственную дизайн-систему, начните с подходящего семейства и набора начертаний. Создайте шрифт под задачи проекта на fontgenerator.ru, а затем подключите его к типографической шкале и семантическим ролям интерфейса.