Контейнерные запросы

Контейнерные запросы

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

Наконец-то это случилось: контейнерные запросы действительно в деле! После того, как нам годами говорили, что это невозможно, в прошлом году произошло наконец движение в нужном направлении. В этом году легенда CSS Miriam Suzanne (и другие) усердно работала над тем, чтобы все двигалось в правильном направлении, и мы, наконец, можем увидеть контейнерные запросы в браузере.

Примите к сведению

Сейчас контейнерные запросы находятся на стадии прототипа и доступны только в Chrome Canary. Чтобы включить контейнерные запросы, перейдите в Chrome по адресу chrome://flags и включите там контейнерные запросы.

Прогрессивный подход

Конечно, первое, на чем я сосредотачиваюсь: как мы можем использовать контейнерные запросы прямо сейчас ? Если браузер не понимает какой-то CSS, он проигнорирует его и продолжит синтаксический анализ остального, поэтому мы можем эффективно использовать контейнерные запросы уже сегодня. Вот как бы я реализовал это:

Это классический пример с проблемой дизайна: как вы справляетесь с неизменным состоянием, когда контейнер card не находится внутри меньшего родительского элемента или небольшого окна просмотра? Конечно, мы можем использовать медиа-запросы, но они не очень полезны, если card окажется в нескольких контекстах — скажем, в дизайн-системе.

Одно быстрое и простое решение, которое мы можем реализовать, — это добавить max-width, поэтому, если контейнер card окажется в большом контексте, он, по крайней мере, не будет выглядеть ужасно.

Все-таки это не идеально, но вполне приемлемо. Это минимальное жизнеспособное решение, которое будет работать абсолютно нормально.

READ
Единицы измерения CSS на основе области просмотра

Давайте будем постепенно использовать контейнерный запрос. Во-первых, давайте сделаем элемент <main> нашим контейнером.

CSS

123main {  contain: layout inline-size;}

Мы будем использовать существующее свойство contain которое помогжет браузеру эффективно работать с контейнерными запросами. Теперь, когда все разобрано, наш card можно дополнить важнейшим блоком @container.

CSS

123456789101112131415161718192021222324252627@container (min-width: 40em) {  .card {    display: flex;    align-items: flex-start;    gap: 1.5rem;    padding: 1.5rem;    max-width: unset;  }   .card h2 {    font-size: 2.5rem;  }   .card__media {    aspect-ratio: 1/1;    flex-basis: 30%;    flex-shrink: 0;  }   .card__media img {    border-radius: 0.5em;  }   .card__content {    padding: 0;  }}

То, что мы делаем здесь, очень похоже на медиа-запрос. Когда контейнер имеет ширину, равную или большую чем 40em, мы можем изменить макет card, чтобы он лучше соответствовал дополнительному пространству. Мы даже стараемся сделать изображение лучше с помошью aspect-ratio.

Контейнерные запросы

Card теперь имеет красивый встроенный макет и квадратное изображение

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

Контейнерные запросы

Card теперь реагирует на размеры своих контейнеров

Возьмем приведенный выше пример. Это гибкий макет, который позволяет дочерним элементам расти, заполняя пространство. C контейнерными запросами нет никаких проблем, потому что мы устанавливаем изменяемые элементы как контейнер, а правила, которые мы устанавливаем для контейнера card, делают все остальное. Удобно!

Наконец, мы можем набирать текст в контексте

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

READ
Длинные URL не сказываются на позициях сайта в Google

Есть еще кое-что, что нужно сделать с типом, который нужно изменять. Многие методы изменяемого типа — вроде того, о котором я писал — полагаются на параметры области просмотра, такие как vw масштабирование. Но мы можем заставить изменяемый тип работать не в области просмотра, а в контексте контейнера:

CSS

1234567891011121314151617/* Before */h1 {  font-size: clamp(    var(—fluid-type-min, 1rem),    calc(1rem + var(—fluid-type-target, 3vw)),    var(—fluid-type-max, 1.3rem)  );} /* After */h1 {  font-size: clamp(    var(—fluid-type-min, 1rem),    calc(1rem + var(—fluid-type-target, 5cw)),    var(—fluid-type-max, 1.3rem)  );}

Подведение итогов

Вот все вышеперечисленное в одной удобной демонстрации. Поэкспериментируйте с ним и посмотрите, что у вас получится.

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

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

Наконец, вот пример демонстрации, которую я сделал, когда впервые познакомился с контейнерными запросами.

Редакция: Команда webformyself.

Читайте нас в Telegram, VK, Яндекс.Дзен

Источник

Оценить статью
Блог о самом интересном.