В этой статье
Scott
Scott

Опубликовано 25.10.2026, обновлено 25.10.2026

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

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

Каталог с карточками в трёх компоновках: с боковой панелью, с двумя колонками и с одной колонкой
Компоновка меняется, но содержание и задача пользователя сохраняются.

Брейкпоинт — это правило, а ширина фрейма — пример

Брейкпоинт, или точка изменения компоновки, задаёт условие перехода к другому поведению. Фрейм в макете показывает один вариант внутри диапазона. Если две колонки появляются с 600 px, фрейм шириной 768 px хорошо их иллюстрирует, но 768 px не становится брейкпоинтом автоматически.

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

Опишите эти два типа поведения отдельно. «Область результатов занимает оставшуюся ширину» — правило размера. «Показывать фильтры сбоку, только если рядом помещаются две удобные для чтения колонки» — условие структурного изменения.

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

Определите минимальную удобную ширину содержания

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

Допустим, после сравнения вариантов команда выбрала для этой карточки минимум 264 px. Это решение для конкретного содержания, а не общая норма. Плотной товарной карточке с ценой и бейджами может понадобиться больше места, а короткой плитке с изображением — меньше.

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

ЭлементШирина в примереЗачем нужно ограничение
Карточка курсаНе менее 264 pxДлинное название и действие остаются удобными
Панель фильтров224 pxПодписи и варианты не переносятся чрезмерно
Промежуток между областями или карточками24 pxГруппы различимы, но интервалы не съедают основную ширину
Внешние поля страницыПо 24 pxСодержание не прилипает к краям окна

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

Рассчитайте переходы между компоновками

Без боковой панели двум карточкам по 264 px нужны промежуток 24 px и суммарно 48 px по краям. Получается 264 + 264 + 24 + 48 = 600 px. Ниже этой ширины используйте одну колонку. Начиная с 600 px при наших исходных условиях помещаются две.

Чтобы показать рядом боковую панель, прибавьте её 224 px и промежуток 24 px: 600 + 224 + 24 = 848 px. Ниже 848 px оставьте вход в фильтры над результатами, а не сжимайте карточки ниже удобной ширины.

Третья колонка добавляет ещё одну карточку и промежуток: 848 + 264 + 24 = 1136 px. Если каталог предусматривает три колонки результатов, следующая кандидатная точка — 1136 px. Добавлять колонки бесконечно не требуется: ограничение максимальной ширины содержания иногда удобнее для чтения.

Ширина окна в примереРезультатыФильтры
Менее 600 pxОдна колонка карточекЭлемент над результатами открывает параметры фильтрации
600–847 pxДве колонкиКомпактный вход в фильтры остаётся над результатами
848–1135 pxДве колонкиБоковая панель шириной 224 px
От 1136 pxТри колонки, если контейнеру хватает местаБоковая панель остаётся видимой

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

Сохраняйте фильтры и порядок чтения

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

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

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

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

Покажите в Pixso обе стороны границы

Подготовьте опорные фреймы шириной 390, 768 и 1024 px. По правилам примера они показывают одну колонку, две колонки без боковой панели и две колонки с панелью. Используйте одни и те же курсы, чтобы сравнивать компоновку, а не разные тексты и иллюстрации.

С помощью Auto Layout и повторно используемых компонентов сохраняйте единую внутреннюю структуру карточек. Разрешите заголовкам и описаниям увеличивать высоту и укажите, какие элементы заполняют доступное место. Рядом с каждым вариантом запишите порог перехода и его причину.

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

Затем проверьте пары 599 и 600 px, 847 и 848 px, 1135 и 1136 px. Последняя ширина перед изменением часто выявляет больше проблем, чем удобный размер в середине диапазона. Посмотрите, не переносится ли заголовок неудачно, не сталкивается ли действие с соседним содержанием и не становится ли карточка слишком узкой.

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

Решите, от чего зависит изменение: окна или контейнера

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

Опишите требование так: «Использовать компактную карточку, когда её контейнер не вмещает горизонтальный вариант», а не «Показывать мобильную карточку на телефонах». Тогда разработчики смогут выбрать запросы к контейнеру, гибкую компоновку или другое решение с учётом поддерживаемых браузеров и архитектуры компонентов.

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

Проверьте другие языки и увеличенный текст

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

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

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

Наверх
Поделиться в X
Поделиться в Facebook