От автора: после многих лет поисков и обсуждений мы, наконец, получаем контейнерные запросы и они изменят дизайн пользовательского интерфейса, как это сделали медиа-запросы.
Наконец-то это случилось: контейнерные запросы действительно в деле! После того, как нам годами говорили, что это невозможно, в прошлом году произошло наконец движение в нужном направлении. В этом году легенда CSS Miriam Suzanne (и другие) усердно работала над тем, чтобы все двигалось в правильном направлении, и мы, наконец, можем увидеть контейнерные запросы в браузере.
Примите к сведению
Сейчас контейнерные запросы находятся на стадии прототипа и доступны только в Chrome Canary. Чтобы включить контейнерные запросы, перейдите в Chrome по адресу chrome://flags и включите там контейнерные запросы.
Прогрессивный подход
Конечно, первое, на чем я сосредотачиваюсь: как мы можем использовать контейнерные запросы прямо сейчас ? Если браузер не понимает какой-то CSS, он проигнорирует его и продолжит синтаксический анализ остального, поэтому мы можем эффективно использовать контейнерные запросы уже сегодня. Вот как бы я реализовал это:
Это классический пример с проблемой дизайна: как вы справляетесь с неизменным состоянием, когда контейнер card не находится внутри меньшего родительского элемента или небольшого окна просмотра? Конечно, мы можем использовать медиа-запросы, но они не очень полезны, если card окажется в нескольких контекстах — скажем, в дизайн-системе.
Одно быстрое и простое решение, которое мы можем реализовать, — это добавить max-width, поэтому, если контейнер card окажется в большом контексте, он, по крайней мере, не будет выглядеть ужасно.
Все-таки это не идеально, но вполне приемлемо. Это минимальное жизнеспособное решение, которое будет работать абсолютно нормально.
Давайте будем постепенно использовать контейнерный запрос. Во-первых, давайте сделаем элемент <main> нашим контейнером.
1 2 3 |
main { contain: layout inline-size; } |
Мы будем использовать существующее свойство contain которое помогжет браузеру эффективно работать с контейнерными запросами. Теперь, когда все разобрано, наш card можно дополнить важнейшим блоком @container.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
@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, делают все остальное. Удобно!
Наконец, мы можем набирать текст в контексте
Что наиболее важно при работе с контейнерными запросами, это то, что мы можем установить типографику контекстно! Для меня это самая необходимая функция в реализациях дизайн-систем, и именно поэтому я хочу, чтобы у нас были запросы к контейнерам. Мы можем отвечать медиа-запросами и таким образом устанавливать размеры шрифтов и т. д., но когда мы не знаем, где окажется элемент, это не идеальный подход. Теперь у нас есть контейнерные запросы, и есть возможность корректировки типов, которые намного упрощают разработку.
Есть еще кое-что, что нужно сделать с типом, который нужно изменять. Многие методы изменяемого типа — вроде того, о котором я писал — полагаются на параметры области просмотра, такие как vw масштабирование. Но мы можем заставить изменяемый тип работать не в области просмотра, а в контексте контейнера:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
/* 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 фактически является прототипом. Приятно наконец увидеть контейнерные запросы на практике и использовать их в браузере. Я буду много рассказывать о них на этом сайте по мере их развития, потому что я совершенно убежден, что контейнерные запросы откроют новую фазу веб-дизайна, столь же важную, как и адаптивный веб-дизайн.
Также обратите внимание, что когда вы смотрели демонстрации в браузере, который не поддерживает функцию контейнерных запросов, они выглядели нормально! Это прогрессивное улучшение в действии, дающее каждому хороший опыт, а при наличии поддержки — оптимальный результат.
Наконец, вот пример демонстрации, которую я сделал, когда впервые познакомился с контейнерными запросами.
Источник: piccalil.li
Редакция: Команда webformyself.
Читайте нас в Telegram, VK, Яндекс.Дзен