Шрифты в адаптивном дизайне: как организовать работу
Привет, это «Кельник». Полгода назад мы начали рассказывать, как работаем со стилями на крупных проектах. Тогда речь шла о том, как контролировать отступы, если у сайта множество страниц, и над ними работает много людей. Сегодня поговорим о шрифтах — как сделать адаптив текстовых стилей на большом проекте и не сойти с ума.
Проблема 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.
Так мы проходимся по всем стилям и выбираем соотношения для каждого брейкпоинта.
Как со стилями работают фронтендеры
В препроцессоре заводится массив, в котором формируют идентичную гайду таблицу шрифтов.
Последним значением в строке идет массив с ratio — то самое соотношение кегля и интерлиньяжа. Если ratio не меняется от брейкпоинта к брейкпоинту, то удобно поставить просто число. Зная размер кегля и ratio, которое выбрал дизайнер, мы можем автоматически вычислить line-height.
Потом применяется миксин:
.b-block {
@include font-size(‘p1’);
}
Если дизайнер придумает новый текстовый стиль, фронтендеру будет несложно добавить новое правило в такую таблицу.
Если дизайнер изменит уже использующийся стиль, то фронтендер просто изменит цифру в таблице — это пара пустяков.
Как со стилями работают дизайнеры
Мы работаем в Скетче и, откровенно говоря, работа с текстовыми стилями там организована на троечку.
Плюс: легко создать и применять иерархию стилей.
Минусы:
— инструмент для обзора/организации стилей примитивный,
— для любой декорации шрифта (вес, цвет, наклон, выравнивание) нужно создавать свой стиль.
Из-за особенностей Скетча таблица текстовых стилей разрастается.
К работе с такой таблицей нужно приноровиться. С помощью нескольких плагинов редактирование таблицы можно оптимизировать до приемлемого состояния.
Зато использовать в работе уже настроенные текстовые стили одно удовольствие.
Мы слышали, что в Фигме работать с текстовыми стилями проще. Расскажите в комментариях, если знаете, как устроена работа со стилями в других программах.
Плюсы и минусы базовых стилей и таблицы шрифтов
Если вы работаете над макетом в одиночку, проект разовый, и сайт не адаптивный, наш подход, скорее всего, вам не подойдёт. Но если в проекте много стилей и участников, а работа растянута по времени, таблица шрифтов существенно облегчает дело.
Чем полезна таблица: дизайнеры оперируют ограниченным количеством стилей, меньше путаются и создают меньше проблем фронтендерам и отделу поддержки. Новые дизайнеры, которые подключаются к проекту, не тонут в море текстовых стилей: если нужно поставить текст на всю ширину контентной колонки, думать не надо — просто используй p1.
Подход далеко не идеальный. Для передачи макетов в вёрстку мы используем связку Скетч-Авокод, и есть большая проблема: в Авокод не передаются названия стилей. Для фронтендеров любой текст в Авокоде — просто набор css, а какой именно стиль — неизвестно. Фронтендер вычисляет нужный стиль из пропорции размера шрифта и интерлиньяжа.
В списке хотелок пользователей Авокода таска про эту проблему висит с 2015 года. Надеемся, что Авокод однажды доберется до неё.
Статью подготовил дизайнер Егор Горохов. Как обычно, мы будем очень рады, если в комментариях вы поделитесь своим опытом работы со шрифтами в больших проектах.
