Запросы контейнера позволяют стилизовать элементы в зависимости от доступного пространства. Они позволяют нам создавать устойчивые компоненты, которые можно адаптировать к бесконечному количеству неизвестных компоновок. Это отличается от медиа-запросов области просмотра, которые требуют, чтобы изменения стиля были согласованы на уровне страницы.
Контейнерные запросы против медиа-запросов Viewport
Скорее всего, мы знакомы с адаптивным дизайном и макетами, которые реагируют на область просмотра, как показано на рисунке ниже.
В адаптивном дизайне окна просмотра популярно связывать сетку макета с контрольными точками. Эти контрольные точки обычно связаны с упрощенными размерами устройств, как показано на рисунке выше, такими как мобильные устройства, планшеты и настольные компьютеры.
Важно отметить, что эти точки останова не обязательно учитывают отдельные элементы и компоненты на экране, а больше фокусируются на том, как компоненты перетекают в предопределенную сетку. Иногда более крупные компоненты, такие как навигация, трансформируются отдельно от сетки, но обычно они используют глобальные контрольные точки.
Давайте сравним адаптивный дизайн окна просмотра с адаптивным дизайном контейнера.
На изображении ниже представлены варианты карточного компонента. Эти три варианта визуализируются с использованием контейнерных запросов, которые полностью не зависят от области просмотра. Стили карт настраиваются в зависимости от доступного места.
Примечание. Контейнерные запросы поддерживаются во всех вечнозеленых браузерах, начиная с версии Firefox 110. Чтобы расширить поддержку старых браузеров, доступен полифилл.
Во-первых, давайте изучим синтаксис для создания контейнерных запросов.
Определение запросов к контейнеру
Первый шаг — указать, что элемент является контейнером, используя свойство container-type. Наиболее фундаментальным и в настоящее время наиболее поддерживаемым значением является inline-size, которое в режиме горизонтального письма соответствует ширине элемента. Таким образом, это определение означает, что мы намерены поддерживать запрос на основе.containerвстроенного размера элемента:
.container { container-type: inline-size; }
Добавление container-typeк элементу официально обозначает его как контейнер.
Далее мы создадим фактический запрос контейнера, используя at-правило контейнера, которое принимает параметр, который будет выглядеть знакомым, если мы когда-либо назначали медиа-запросы.
Следующее @containerправило гласит, что если объект находится внутри контейнера, 40chширина которого или больше, его цвет должен быть синим:
@container (min-width: 40ch) { h2 { color: blue; } }
Примечание: правила, которые мы размещаем в запросе контейнера, не будут влиять на стиль самого контейнера, а только на его дочерние элементы. Это означает, что мы не можем стилизовать контейнер из его собственного запроса. Но мы можем стилизовать контейнер с запросом контейнера, если у этого контейнера есть предок, который также определен как контейнер.
Чтобы учесть больше, чем горизонтальные режимы записи, мы можем обновить наш запрос, чтобы использовать логический синтаксис inline-sizeвместо того, чтобы основывать запрос строго на «ширине» контейнера:
@container (inline-size > 40ch) { h2 { color: blue; } }
Вариантов больше, чем просто inline-size, в том числе block-sizeи aspect-ratio. Чтобы узнать больше о запросах контейнеров доступных размеров и о том, как их использовать, ознакомьтесь с официальной спецификацией.
Обновление компонента карты
Если бы мы хотели создать компонент карты без запросов к контейнеру, мы могли бы создавать варианты с помощью классов модификаторов. А для вариаций размера карты эти модификаторы могут быть привязаны к контрольным точкам. Это означает, что если бы у карты был модификатор, его можно было бы изменить, когда ширина области просмотра попала в эту точку останова.
На следующем изображении показаны три варианта размера карты и соответствующие им классы модификаторов, где верх.cardбудет считаться «по умолчанию».
Вот живая демонстрация CodePen карточек, реагирующих на область просмотра, изображенных выше. (Измените размер области просмотра, чтобы увидеть, как работают различные стили.)
Давайте теперь сменим нашу перспективу и подумаем, как мы будем обрабатывать эти варианты карточек, используя контейнерные запросы.
Мы по-прежнему будем использовать верхнюю карту по умолчанию, что на самом деле означает, что она будет применяться при самой узкой ширине. Это также будет резервная версия, в которой контейнерные запросы не поддерживаются — важный сценарий, который следует учитывать до тех пор, пока контейнерные запросы не достигнут зрелости поддержки.
Мы установим макет для карты среднего размера (с горизонтальной ориентацией), чтобы он активировался, когда контейнер имеет ширину 350pxили больше.
Наконец, мы настроим макет карты на использование ее изображения в качестве фона, когда контейнер имеет ширину 600pxили больше.
Это создает элемент карты, который можно адаптировать в зависимости от размера контейнеров для карт.
