Брейкпоинты, медиазапросы и контейнерные запросы

Брейкпоинт ставят там, где ломается контент, а не там, где «iPhone заканчивается». Устройств бесконечно много — точек излома должно быть мало и по делу.

«Не дизайнь под устройства. Дизайнь под контент — устройства приходят и уходят».

Брейкпоинт — это ширина, на которой макет меняет раскладку. Распространённая ошибка — привязывать их к конкретным телефонам. Моделей сотни, и завтра выйдет новая. Правильный подход: расширяйте окно, и как только строки стали слишком длинными или блок «развалился» — ставьте брейкпоинт здесь.

Типовая шкала

Революция: контейнерные запросы

Медиазапросы смотрят на ширину окна. Но компонент-карточка может стоять и в широком герое, и в узком сайдбаре — а ширина окна одна. Container queries (поддержаны во всех актуальных браузерах с 2024 года) решают это: компонент реагирует на ширину своего родителя, а не экрана. Это делает компоненты по-настоящему переиспользуемыми.

/* Объявляем родителя контейнером */
.card-wrap { container-type: inline-size; }

/* Карточка реагирует на ширину родителя, не окна */
.card { display: grid; gap: 8px; }

@container (min-width: 400px) {
  .card {
    grid-template-columns: 120px 1fr;  /* фото слева */
  }
}

  MEDIA vs CONTAINER
  ------------------
  Окно широкое, но карточка в узком сайдбаре:

  media-query видит ШИРОКОЕ окно -> ломает карточку
  container видит УЗКИЙ сайдбар  -> карточка корректна

  [ широкий герой: фото|текст ]   [сайдбар:]
                                  [ фото   ]
                                  [ текст  ]

Разбор глубже: от устройств к контенту и компонентам

История брейкпоинтов — это история освобождения от устройств. Когда-то верстали под «320, 768, 1024» — ширины конкретных iPad и iPhone своего времени. Но устройств стали сотни, экраны — любых размеров, появились складные телефоны и сверхширокие мониторы. Привязка к моделям устарела мгновенно. Современный принцип прост и устойчив: медленно растягивайте окно и ставьте брейкпоинт ровно там, где макет начинает выглядеть плохо — строки стали слишком длинными, между колонками зазияли дыры, кнопки разъехались. Так брейкпоинты привязаны к вашему контенту, а не к чужому железу, и не устаревают.

Контейнерные запросы — это, возможно, главное изменение в адаптивной вёрстке за последнее десятилетие. Корень проблемы, которую они решают: медиазапрос знает только ширину окна, но компонент-карточка живёт в разных контекстах — то в широком герое, то в узком сайдбаре, то в модалке. При широком окне медиазапрос «думает», что места много, и раскладывает карточку в две колонки — даже если она стоит в узком сайдбаре и две колонки туда не влезают. Container queries дают компоненту знание о ширине его родителя, и карточка адаптируется к реальному доступному месту.

Последствие глубже, чем кажется: container queries наконец делают компоненты по-настоящему переиспользуемыми. Раньше «адаптивная карточка» была полуправдой — она была адаптивна только в том месте, где её настроили. Перенеси в другую колонку — сломается. С контейнерными запросами карточка несёт свою адаптивность с собой и ведёт себя корректно где угодно. Это меняет саму архитектуру дизайн-систем: компонент проектируют один раз как самодостаточный, а не подстраивают под каждую страницу. С 2024 года технология поддержана во всех актуальных браузерах, так что это уже не эксперимент, а рабочий инструмент.

Как делают ПЛОХО

Ставят десяток брейкпоинтов под каждую модель iPhone и Galaxy. На новом устройстве с нестандартной шириной всё разъезжается. Компоненты ломаются при переносе в другую колонку, потому что завязаны на ширину окна.

Как делают ХОРОШО

2–4 брейкпоинта, поставленных там, где реально ломается контент. Переиспользуемые компоненты используют container queries и работают одинаково в любом контексте — герой, сайдбар, модалка.

Чек-лист

• Брейкпоинты привязаны к контенту, а не к моделям устройств.
• Их немного (2–4), и каждый оправдан.
• Переиспользуемые компоненты используют container queries.
• Карточка одинаково корректна в герое и в узком сайдбаре.

Итог. Брейкпоинты ставят по контенту, а не по устройствам. Container queries позволяют компоненту реагировать на родителя — и стать по-настоящему переиспользуемым.