На днях прочла статью, в которой Set Studio собрали статистику по разрешениям окна браузера на основе 120 000 сессий пользователей. Вышло более 2300 вариантов. Главный вывод авторов: какого-то одного оптимального вьюпорта не существует, а значит адаптивность должна быть гибкой.
И если раньше я не собиралась писать текст о том, как несколько месяцев назад начала по-новому работать над адаптивностью на своих веб-проектах, то теперь мне немедленно захотелось это сделать. Потому что у меня как раз есть подход как такой гибкости добиться.
Забавно, что этот подход родился тоже после прочтения другой статьи. В ней автор призывал не держаться парадигмы фиксированных брейкпонтов и не делать упор на адаптивность всей страницы целиком. Вместо этого он предлагал пользоваться всеми мощными функциями CSS чтобы делать адаптивными отдельные компоненты и позволять браузеру самостоятельно решать, когда компонент должен иметь определенный вид. Автор обещал, что так мы соберем лейаут, который будет максимально гибко работать на любом девайсе.
Но хоть статья была длинная и с множеством примеров, все равно было не до конца понятно, что же теперь надо делать по-новому. Так как главными расширяющими возможности CSS-функциями автор назвал контейнерные запросы и min(), max() и clamp(), я пошла ресёрчить именно их. Оказалось, что оригинальная статья не сообщала чего-то супер нового. Материалы похожего содержания появлялись начиная с 2020 года. Хоть бы один разраб рассказал что происходят такие перемены! Будем считать, что еще одна мораль этой статьи — дизайнеру полезно погружаться не только в креатив кодинг, но и в такие утилитарные штуки.
В итоге, после поисков, примерок и тестов, у меня сформировался подход. Но прежде чем описать его, я расскажу как выглядел мой прошлый флоу.
Как раньше выглядела моя работа над адаптивом
Обычно, всё начиналось с того, что перед тобой лежат два макета: какой-нибудь распространенный десктоп, скажем 1440 px, и мобилка. Твоя задача понять что будет происходить на градиенте между ними, а так же далее, на больших мониторах.
И тут я отталкивалась от девайсов и самых распространенных разрешений. Как правило, первым появлялся макет для планшета. Пусть процент этих устройств исчезающе мал, но он сочетает в себе элементы как мобильного, так и десктопного UX — такой гибрид является важным переходным брейкпоинтом по своей сути. Хорошо бы также нарисовать макет для 1024 px — это горизонтальный планшет и некоторые совсем маленькие десктопы. Но до 1440 px еще далеко, поэтому надо поставить еще одну засечку: 1280 px или 1360 px. Ну и под занавес — 1920 px.
Что не так с таким подходом? Основной минус в том, что мы отталкиваемся от распространенных числовых брейкпоинтов, а не от фактических нужд компонентов страницы. А компоненты, как правило, очень неоднородны: поведение одних можно описать одним макетом и двумя строчками текста, а для других по-хорошему надо задать 6–7 состояний и нарисовать детализированный макет для каждого из них. Причем какому-то блоку лучше совершить перекомпановку на 1300 px, не дожидаясь 1360 px, но он не может этого сделать, потому что всем его соседям предпочтительнее совершить скачок попозже. В итоге все блоки всей гурьбой скачут по одним и тем же брейкпоинтам, надо им это или нет. Это совершенно не про гибкость. И еще один минус — надо рисовать дохрена макетов.
Как теперь я работаю над адаптивом
Начало такое же, перед тобой два макета: десктоп и мобилка. Но теперь мы работаем с каждым блоком страницы в отдельности и думаем над его поведением без оглядки на соседей сверху и снизу. Ну почти без оглядки, но об этом позже.
Для примера, возьмем header: на мобилке навигация свернута в бургер. Развернуть её я могу уже на 955 px. Это не какое-то распространенное разрешение, таких девайсов нет, просто начиная с 955 px у хедера появляется достаточно места. Ну пусть он там и разворачивается! А дальше уже никаких других макетов не надо: логотип остается по центру, а навигационные элементы всегда прибиты к краям страницы.
Далее идёт блок hero. Поменять мобильную сборку на какую-то другую он готов на 670 px. Нам нет нужды ждать планшетных 768 px, как и нет нужды сверять свои действия с хедером. Пришла пора перекомпоноваться — вперед. Возможно, дальше какие-то изменения понадобятся только на 1400 px, так что можно за раз скипнуть ощутимый кусок ненужной отрисовки.
Но если я вижу, что компоненты готовы измениться на очень близких числовых значениях, я привожу их к общему знаменателю. Если у одного блока это 1095 px, а другого 1100 px, то скорее всего я создам для них общий брейкпоинт. Просто чтоб легче было держать все эти цифры в голове.
Так мы работаем с каждым блоком страницы, пока не опишем их все. В итоге оказывается, что каким-то блокам нужно совсем немного отдельно отрисованных состояний, а другим — наоборот, нужно больше чем обычно.
Когда я начинала практиковать такой подход у меня была одна главная тревога — а вдруг эти независимо нарисованные компоненты не сойдутся вместе. Ведь на странице как правило есть вертикальные направляющие, которые компоненты должны согласованно соблюдать.
Тут мне помогают глобальные правила для сетки и шрифтовых стилей. Например, я решаю что для всего градиента возможной ширины вьюпорта у меня будет только три варианта сетки. И в каких бы числовых значениях у блока не случился брейкпоинт, он всегда опирается на сетку, которая работает в этом отрезке. То же самое для шрифтовых стилей: я задаю правило, что на этом отрезке у меня один набор стилей, а на этом — другой. Такие правила не дают макету развалиться.
Ну и конечно, в случае сомнений всегда можно по-быстрому примерить блочки друг к другу. Обычно это нужно только в начале проекта, потом система в голове складывается и места где может что-то рассинхронизироваться чуешь интуитивно.
И есть один важный момент, приготовьтесь: подобная проработка может быть многоуровневой. Можно нарисовать как блок с карточками перегрупировывается при изменении ширины вьюпорта, а следом — как элементы внутри карточки меняется при изменении её собственной ширины.
Наиболее наглядна эта многоуровневость видна на примере ниже. Тут показаны не два разных типа карточек (большая и маленькая), а один и тот же компонент, просто левая лежит в контейнере поменьше, а правая — в контейнере побольше. Мы начинаем менять ширину вьюпорта и меняется ширина контейнеров — карточки уменьшаются. В какой-то момент правая карточка становится точно такой же какой была левая в самом начале. То есть это один и тот же элемент, который принял разный вид, ориентируясь на свойства родителя.
В итоге, по ощущениям, работа над ресайзами в новом подходе не стала занимать у меня сильно меньше времени, но совершенно точно распределено оно теперь более эффективно. Разработчиков новая логика макетов тоже устроила, хоть и немного удивила вначале.
Если заинтересовала тема, советую прочитать еще эти материалы:
