Шрифты в адаптивном дизайне: как организовать работу

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

Проблема 1: разнообразие текстовых стилей

В процессе работы над макетами дизайнер собирает гайдлайн по шрифтам. Минимально туда прописываются заголовки от h1 до h6, параграфы, списки, и т.д.

Обычно такой гайдлайн выглядит примерно так.

В чем тут проблема? Для параграфов дизайнер придумывает имена — bodyText, mainText, smallParagraph, factoidRedCenter, navigationLinks. Со временем количество таких стилей возрастает, следить за ними становится сложнее.

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

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

Решение: базовые текстовые стили

В html по умолчанию прописаны теги для иерархии из 6 заголовков. Для них заведены специальные теги — от <h1> до <h6>. Так было со второй версии html (1995 год), но при этом не была придумана иерархия для параграфов. Для текста есть только один тег — <p>.

Мы решили, что так не годится, и внутри себя придумали базовые стили для текста. Основной текст — p1. Помельче — p2. Еще мельче — p3. Ну вы поняли, да? Количество не ограничено.

В таблице указывается две переменных — кегль (размер шрифта) и интерлиньяж (межстрочное расстояние).

Любой из этих стилей применяется к разным элементам. Например, стиль р2 ставится и в фактоид, и в узкую колонку, и как ссылка в футере.

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

Проблема 2: шрифты в адаптивном дизайне

Современные сайты адаптивны. Они создаются с расчётом не на одно разрешение экрана, а на брейкпоинты — 1920, 1366, 320. На каждом брейкпоинте происходит «перескок» от одной композиции экрана к другой.

В зависимости от задач мы используем от 3 до 6 таких «перескоков». Текстовые стили меняются от брейкпоинта к брейкпоинту. Уследить за всеми стилями, особенно если они не подведены к базовым, нелегко.

Дизайнерам нужно поддерживать гайд по текстовым стилям в актуальном состоянии в процессе адаптирования макетов под разные брейкпоинты. Любой неопределенный стиль в макете создает проблемы — на одном адаптированном макете он стал 16/24, на другом 14/22 — стили начинают «плясать».

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

Решение: таблица адаптивности текстовых стилей

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

Когда дизайнер рисует адаптивные макеты, встает вопрос о пропорциях в типографике. Например, если на десктопе размер шрифта 20, а интерлиньяж 28, то на мобилке размер шрифта ставится 14, а интерлиньяж выбирается рандомно — может 16, а может и 20.

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

Чтобы оптимизировать этот процесс, мы создали простенький скрипт, который вычисляет ratio — соотношения размера шрифта и интерлиньяжа. С этим инструментом ясно, что десктопный параграф размером 20/28 на мобилке будет 14/20.

Наш собственный инструмент для вычисления соотношений — https://readymag.com/kelnik/960360/

Так мы проходимся по всем стилям и выбираем соотношения для каждого брейкпоинта.

Как со стилями работают фронтендеры

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

Последним значением в строке идет массив с ratio — то самое соотношение кегля и интерлиньяжа. Если ratio не меняется от брейкпоинта к брейкпоинту, то удобно поставить просто число. Зная размер кегля и ratio, которое выбрал дизайнер, мы можем автоматически вычислить line-height.

Потом применяется миксин:

.b-block {
@include font-size(‘p1’);
}

Если дизайнер придумает новый текстовый стиль, фронтендеру будет несложно добавить новое правило в такую таблицу.

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

Как со стилями работают дизайнеры

Мы работаем в Скетче и, откровенно говоря, работа с текстовыми стилями там организована на троечку.

Плюс: легко создать и применять иерархию стилей.

Минусы:

— инструмент для обзора/организации стилей примитивный,

— для любой декорации шрифта (вес, цвет, наклон, выравнивание) нужно создавать свой стиль.

Из-за особенностей Скетча таблица текстовых стилей разрастается.

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

Зато использовать в работе уже настроенные текстовые стили одно удовольствие.

Плюсы и минусы базовых стилей и таблицы шрифтов

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

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

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

В списке хотелок пользователей Авокода таска про эту проблему висит с 2015 года. Надеемся, что Авокод однажды доберется до неё.

Источник