# Адаптивная вёрстка сайта: что согласовать и как принять работу

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

Автор: Редакция KEIVO
Дата публикации: 2026-10-31
Канонический URL: https://keivo.ru/blog/adaptivnaya-verstka-sayta/

Принимать адаптивную вёрстку нужно по поведению страницы на разных ширинах и в разных состояниях — два совпавших скриншота ещё не описывают готовую работу



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

Она не требует от заказчика знания CSS — нужно перечислить страницы, важные действия, варианты содержимого и признаки исправной работы

## Что входит в адаптивную вёрстку

Адаптивная страница перестраивает представление под доступное пространство — меняются колонки, переносы, размеры изображений и расположение элементов, сохраняя содержание и доступ к действиям

[MDN описывает responsive design](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design) как подход с гибкими сетками, медиа и правилами для разных условий — это полезная основа, но не готовый перечень обязательств конкретного исполнителя

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

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


![Генеративная иллюстрация: одна вымышленная страница на мониторе, планшете и телефоне](/blog/_media/m7-20261031/m22-cover-1445ced448ad.webp)

Генеративная иллюстрация KEIVO — вымышленный интерфейс, не снимок клиентского сайта и не результат измерения



## Какие страницы считать разными шаблонами

Соберите список типов страниц: услуга, статья, каталог, карточка и документы, если они предусмотрены проектом — рядом запишите реальные адреса или согласованные макеты

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

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

Сгруппируйте адреса по общим шаблонам — тогда будет видно, где достаточно исправить один компонент, а где нужно проверить отдельное устройство страницы

## Как договориться о ширинах и браузерах

Зафиксируйте основные размеры из макетов и диапазоны между ними — конкретные контрольные ширины выбирайте по сетке и аудитории, а не по одному списку популярных телефонов

Попросите проверить плавное изменение ширины — переход от трёх колонок к двум должен происходить до того, как карточки становятся непригодными для чтения

Браузеры и устройства перечислите отдельно — если есть данные посещений, они помогут выбрать приоритеты, а при отсутствии данных набор нужно согласовать явно

Эмуляция полезна для диапазона ширин, но реальные устройства остаются отдельной проверкой — это ограничение объясняется в [документации Chrome Device Mode](https://developer.chrome.com/docs/devtools/device-mode/)

### Как выбрать контрольные ширины по содержимому

Начните с блока, которому теснее всего при уменьшении окна — это может быть сетка карточек, строка навигации, сравнительная таблица или группа кнопок

Посмотрите, в какой момент ухудшается чтение или управление — название переносится неудачно, действие прижимается к соседнему, карточки становятся слишком узкими для своего содержимого

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

Учебный расчёт для сетки: у карточки согласована удобная ширина 280 пикселей, между карточками 24 пикселя, боковые отступы контейнера по 32 пикселя — три колонки занимают `3 × 280 + 2 × 24 + 2 × 32 = 952` пикселя

Для этого примера команда может выбрать переход около 960 пикселей — затем проверить не только 960, но и 959, чтобы убедиться, что обе стороны границы работают

Две такие колонки с теми же отступами занимают 648 пикселей — ниже этой границы понадобится один столбец или другое согласованное решение

На самом узком экране отступы могут уменьшаться отдельно — например, при ширине 320 пикселей поля по 20 оставляют карточке 280 — это тоже часть решения, которую нужно записать

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

### Как выбрать браузеры без выдуманной статистики

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

Затем согласуйте набор реальных устройств и способы дополнительной эмуляции — указание «мобильные браузеры» не объясняет, проверялся ли Safari на iPhone или только узкое окно Chrome на компьютере

Если статистики пока нет, выберите явный стартовый набор и пометьте основание как предположение — например, доступные Chrome на Android, Safari на iPhone и настольные браузеры из задания

Не подменяйте отсутствие устройства обещанием поддержки — исполнитель должен показать, что реально проверено, а что остаётся согласованным ограничением

## Какие состояния часто забывают

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

Согласуйте поведение при длинном названии, отсутствующей картинке и увеличенном тексте — используйте осмысленное содержимое, а не набор случайных букв

Для интерактива запишите, что остаётся доступно без JavaScript — например, статья должна сохранять объяснение и ссылку на документ, даже если вспомогательный чек-лист не пересчитывается

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




| Объект | Состояние | Проверка | Критерий приёмки |
|---|---|---|---|
| Статья | Длинный заголовок | Узкая и промежуточная ширина | Слова не обрезаны, действия доступны |
| Карточки | Неполный последний ряд | Изменение ширины окна | Порядок чтения сохранён, карточки не перекрываются |
| Меню | Открыто | Телефон и клавиатура | Ссылки доступны, панель можно закрыть |
| Таблица | Много столбцов | Дойти до последней ячейки | Значения читаемы, вся страница не уезжает вбок |
| Форма, если есть | Ошибка ввода | Неверное значение и исправление | Сообщение связано с полем, введённые данные не теряются без причины |
| Файл | Скачивание | Открыть документ | Файл доступен и соответствует подписи |




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

## Как выглядит заполненная матрица приёмки

Рассмотрим учебный сайт мастерской — у него есть услуга ремонта, статья с памяткой и сравнительная таблица условий — набор выбран, чтобы проверить разные типы содержимого

Для этой работы согласованы контрольные ширины 320, 412, 648, 959, 960 и 1440 пикселей — крайние точки показывают узкую и широкую подачу, а соседние значения проверяют переходы учебной сетки

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




| Страница или блок | Контент и состояние | Контроль | Что принимаем |
|---|---|---|---|
| Услуга ремонта | Длинное название и два действия | 320 и 412, настоящий телефон | Название полностью видно, действия различимы и доступны |
| Сетка услуг | Три карточки и неполный ряд | 959/960 и 648, изменение окна | Число колонок меняется без наложения и потери порядка |
| Статья | Длинная ссылка, список и иллюстрация | Узкая и широкая подача | Ссылка читается, подпись относится к картинке, текст не уезжает вбок |
| Условия | Широкая таблица | 320/412 и клавиатура | Все столбцы доступны внутри блока, страница не расширяется |
| Общее меню | Открыто, закрыто, переход по якорю | Телефон, клавиатура, смена ширины | Панель закрывается по сценарию, фокус и прокрутка не теряются |
| Памятка | Открытие и сохранение документа | Телефон и компьютер | Файл соответствует подписи и согласованной версии |




В реальном задании добавьте к этим строкам точные адреса — иначе проверяющий может выбрать другой экземпляр страницы с более коротким текстом и не повторить нужную ситуацию

Для каждой строки удобно оставить результат, ссылку на доказательство и статус — «не проверено» отличается от «проверено, замечаний нет» и не должно превращаться в зелёную отметку

### Как заполнить одну строку полностью

Объект: услуга ремонта с длинным названием — условие: Chrome на согласованном Android, вертикальная ориентация — действие: открыть меню и перейти к условиям

Ожидается: выбранный блок виден, меню закрыто, страницу можно прокручивать — наблюдается: панель закрылась, но страница осталась заблокированной

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

У такой строки есть завершение — повторный проход на опубликованной версии с зафиксированным результатом — запись «разработчик сообщил, что готово» сама по себе её не закрывает

## Что делать, если мобильного макета нет

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

Перестройка обычной сетки в один столбец может следовать существующему шаблону — но превращение сложной таблицы в набор карточек меняет представление данных и требует обсуждения

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

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

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

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

## Как отличить дефект от нового пожелания

Дефект нарушает согласованное поведение — например, карточка перекрывает кнопку на ширине внутри принятого диапазона

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

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

Учебная формулировка: «Таблица сравнения остаётся таблицей — на узком экране прокручивается внутри своего блока, заголовки и все значения доступны — общий контейнер страницы не расширяется»

Такое описание проверяется — фраза «сделать красиво на мобильном» оставляет слишком много разных трактовок

## Как оформить результат приёмки

### Как вести список замечаний

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

Не собирайте разные дефекты одной строкой «исправить мобильную вёрстку» — после частичной правки будет непонятно, что осталось и почему задача считается незавершённой

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

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

### Что должно остаться в результате приёмки

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

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

Появление нового длинного названия или большого документа после запуска — повод проверить затронутую строку заново — прежняя приёмка не подтверждает любой будущий контент автоматически

### Как закрепить требования к наполнению

Для повторяющегося блока запишите, какое содержимое уже использовалось в проверке — длину названия, наличие пояснения, соотношение сторон изображения, возможное отсутствие второстепенного поля

Это помогает редактору обновлять сайт — например, название услуги может занимать несколько строк, но добавление в кнопку всего описания требует отдельной проверки, потому что меняется роль элемента

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

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

### Как завершить учебную приёмку

Для версии v1 матрица сохранила проблемы сетки, таблицы и меню — после передачи версии v2 проверяющий повторяет каждую соответствующую строку, затем рабочий контрольный пример статьи

Если длинная карточка теперь помещается на 959 и 960, но таблица всё ещё обрезана, закрывается только первое замечание — общий статус «мобильный адаптив готов» пока не соответствует результатам

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

Так матрица становится основанием приёмки, а не списком галочек к макету — она показывает, какое поведение действительно подтвердили и что нужно проверить после следующего изменения

## Что принять до публикации и после неё

До выпуска проверьте все согласованные шаблоны и состояния на сборке-кандидате — сохраните список замечаний, выполненных исправлений и ограничений проверки

После публикации повторите основные маршруты на домене — проверьте изображения, ссылки, загрузку документов и адреса после перенаправлений

Публичный замер скорости отличается от локального — на результат влияют сеть и сервер, поэтому в отчёте должны быть адрес, устройство, время и условия измерения

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

Для отдельного прохода используйте [план мобильной проверки](/blog/proverit-mobilnuyu-versiyu-sayta/) — для подготовки исходников перед работой пригодится [разбор передачи макета в вёрстку](/blog/podgotovit-maket-k-verstke/)

## Что передать исполнителю

Соберите макеты, реальные тексты, список шаблонов и матрицу состояний — рядом укажите, какие решения уже приняты, а какие нужно предложить

На [странице вёрстки KEIVO](/services/verstka/) можно сверить общий состав работ — конкретный объём определяется вашим набором страниц и поведения

[Скачать матрицу приёмки адаптивной вёрстки](/materials/m7-priemka-adaptiva.md) — с примером строки, полями для устройств и отдельными проверками до и после выпуска

## Достаточно ли вводных для приёмки




- [ ] Выбраны страницы для проверки


- [ ] Определены условия проверки


- [ ] Учтены состояния блоков


- [ ] Понятен порядок приёмки






Без интерактива проверьте эти же четыре пункта вручную — список помогает подготовить приёмку, но не тестирует сайт автоматически

Источники проверены 31 октября 2026 года — матрица и пример требований подготовлены редакцией KEIVO