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

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

Дата актуальности: 28 августа 2026 года. В статье используется практический подход без привязки к конкретному фреймворку: он подходит для CSS, нативной разработки и кроссплатформенных приложений.

Типографический токен — именованная переменная, которая описывает один параметр или готовую роль текста. Например, token.body.md может задавать основной текст, а token.heading.lg — крупный заголовок. В токене могут храниться размер шрифта, высота строки, насыщенность, семейство и дополнительные параметры. Вместо десятков разрозненных значений команда работает с понятным словарём дизайн-системы.

Важно разделять базовые и семантические токены. Базовые токены описывают шкалу: например, font.size.16, font.size.20 или font.weight.600. Семантические токены отвечают на вопрос, где используется значение: text.body.default, text.label.strong, text.heading.page. Именно семантический слой позволяет заменить шрифт или пересобрать шкалу, не меняя названия компонентов.

Расхождения появляются, когда каждая платформа создаёт типографику независимо. Веб-команда может измерять текст в пикселях и rem, мобильная команда — в пунктах или платформенных единицах. Кроме того, браузер и мобильная операционная система по-разному интерпретируют метрики шрифта, сглаживание, переносы, системные отступы и доступность.

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

Начните с инвентаризации всех текстовых ролей продукта. Не копируйте существующие стили как есть: сначала объедините похожие назначения. Например, стили «заголовок экрана», «заголовок страницы» и «название раздела» могут стать одной ролью, если выполняют одинаковую задачу. Отдельно зафиксируйте исключения: крупные промо-заголовки, табличные данные, технические подписи и текст ошибок.

Пример семантической шкалы может выглядеть так: heading.page, heading.section, body.large, body.medium, body.small, label.medium и caption. Такие имена не обещают конкретный размер навсегда. Если после тестирования основной текст изменится с 16 до 17 единиц, компонентам не придётся переименовывать стили или искать все старые значения.

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

Указывайте начертания явно. Роли regular, medium, semibold и bold должны иметь согласованные значения на обеих платформах. Не рассчитывайте, что браузер или мобильная библиотека корректно создаст искусственное полужирное начертание. Подмена может изменить форму знаков и сделать иерархию непредсказуемой.

Общий источник токенов не означает, что веб и приложение должны получать один и тот же файл без преобразований. Общая модель хранит намерение, а платформенные файлы переводят его в нужный синтаксис. В вебе это могут быть CSS-переменные, в нативной разработке — типизированные структуры, в кроссплатформенном проекте — объекты темы и адаптеры для конкретного UI-слоя.

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

Допустим, продукт использует роль body.medium. В общем словаре она описывается как основной текст интерфейса с обычным начертанием и комфортной высотой строки. В веб-слое роль получает CSS-значения для font-size и line-height, а в мобильном слое — значения, совместимые с типографической системой платформы. Название и назначение остаются одинаковыми, а техническая реализация может различаться.

Высота строки связывает типографику с компоновкой. Если размер текста одинаковый, но line-height различается, блоки на вебе и мобильном устройстве будут иметь разную высоту. Это особенно критично для списков, кнопок, полей формы, навигации и карточек с ограниченным пространством. Поэтому для каждой роли задавайте не только размер, но и правило вертикального ритма.

Проверяйте токены на коротких и длинных строках, в одну и две строки, с кириллицей, цифрами и знаками препинания. Строка «Настройки уведомлений» может занимать одно место в веб-версии и переноситься в мобильной. Если высота строки и внутренние отступы не согласованы, интерфейс будет выглядеть сломанным даже при одинаковом шрифте.

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

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

Соберите список используемых текстовых стилей из макетов, веб-кода и мобильного приложения. Объедините дубли, найдите значения, которые отличаются только названием, и отметьте компоненты с локальными переопределениями. Результатом должен стать не идеальный словарь, а прозрачная карта текущего состояния: какие роли существуют, где они используются и какие проблемы уже заметны.

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

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

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

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

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

Имена вроде small-gray или big-bold быстро устаревают. Когда роль меняет размер или цвет, название начинает вводить в заблуждение. Используйте назначение: body.default, button.label, heading.screen. Это облегчает масштабирование дизайн-системы и перевод интерфейса на другую платформу.

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

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

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

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

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

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

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

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

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