Контейнерные запросы CSS для дизайнеров

От автора: работа над веб-дизайном включает в себя разработку дизайна для экранов разных размеров. На основе этих дизайнов разработчик будет использовать медиа-запросы CSS для определения ширины или высоты области просмотра, а затем изменять дизайн на основе этого. Именно так мы разрабатывали веб-макеты последние 10 лет, и скоро этот процесс станет еще лучше. У меня для Вас хорошие новости.

Контейнерные запросы CSS, давно запрашиваемая веб-разработчиками функция, скоро появится в CSS и теперь доступна в качестве экспериментальной функции в Chrome Canary. В этой статье я расскажу, что это такое, как это изменит ваш рабочий процесс как дизайнера и многое другое. Не важно, являетесь ли вы дизайнером, который кодирует или нет, поскольку основная цель этой статьи — представить концепцию, чтобы вы могли быть готовы к изменениям. Если вы заметите какие-либо CSS, которые не полностью понимаете, вы можете игнорировать их и двигаться дальше.

Довольно слов, давайте разбираться!

Текущее состояние адаптивного дизайна

В настоящее время все еще можно работать с несколькими версиями одного и того же веб-макета, чтобы показать, как внутренние компоненты будут меняться в зависимости от ширины области просмотра. Мы разрабатываем разные размеры, такие как мобильные, планшетные и настольные.

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

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

Обратите внимание, что это один и тот же компонент, и у него есть три варианта: по умолчанию, карточный и рекомендуемый. Как дизайнер вы использовали несколько версий макета, чтобы продемонстрировать это. Это все равно что сказать: «Вот так компонент статьи будет выглядеть на мобильных устройствах, и так он будет выглядеть на планшетах».

В CSS разработчику необходимо создать три варианта этого компонента, и каждый из них уникален. Рассмотрим следующие основные стили:

.c-media { /* the default styles */ display: flex; flex-wrap: wrap; gap: 1rem;
} @media (min-with: 400px) { .c-media--card { display: block; } .c-media--card img { margin-bottom: 1rem; }
} @media (min-with: 1300px) { .c-media--featured { position: relative; /* other styles */ } .c-media--featured .c-media__content { position: absolute; left: 0; top: 0; width: 100%; height: 100%; }
}

Приведенные выше варианты зависят от медиа-запросов или ширины области просмотра. Это означает, что мы не можем управлять ими на основе их родительской ширины. Теперь вы можете спросить, в чем проблема? Что ж, это хороший вопрос.

Проблема в том, что разработчик связан с использованием варианта компонента только тогда, когда ширина области просмотра больше определенного значения. Например, если я хочу использовать «рекомендованный» вариант размера планшета, это не сработает, почему? Потому что медиа-запрос для него срабатывает при ширине области просмотра 1300px или больше.

Не только это, но мы также можем столкнуться с проблемой, когда контент меньше ожидаемого. Иногда автор контента добавляет только одну статью, в дизайн которой было включено три из них. В таком случае либо у нас будет пустое место, либо статья расширится, чтобы заполнить доступное пространство. Рассмотрим следующий рисунок:

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

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

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

Что такое контейнерные запросы?

Во-первых, позвольте мне определить, что такое контейнер. Это элемент, который содержит другой элемент(ы) и иногда называется оболочкой. Прототип контейнерных запросов теперь доступен в Chrome Canary. Благодаря усилиям многих людей, таких как Мириам Сюзанна и других.

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

Обратите внимание, что каждая карточка имеет желтый контур, который представляет родительский элемент для каждого компонента. С помощью контейнерных запросов CSS мы можем изменять компонент в зависимости от его родительской ширины. Чтобы было понятнее, вот HTML-разметка для вышеизложенного:

<div class="o-grid"> <div class="o-grid__item"> <article class="c-media"></article> </div> <!-- + more items -->
</div>

Компонент — это элемент с классом .c-media, а его родительский элемент — это элемент .o-grid__item. В CSS мы можем cделать следующее:

.o-grid__item { contain: layout inline-size style;
} .c-media { /* Default style */
} @container (min-width: 320px) { .c-media { /* The styles */ }
} @container (min-width: 450px) { .c-media { /* The styles */ }
}

Сначала мы сказали браузеру, что каждый элемент с классом .o-grid__item является контейнером. Затем мы сказали браузеру, что если ширина родительского элемента равна или больше 320 пикселей, он должен выглядеть по-другому. То же самое и для запроса 450 пикселей. Вот как работают запросы контейнера CSS.

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

Слева это окно просмотра, размер которого изменяется. Справа компонент, который изменяется в зависимости от ширины его родительского элемента. Вот насколько мощные и полезные контейнерные запросы.

Проектирование с учетом контейнерных запросов

Как дизайнеру, вам необходимо адаптироваться к этой революционной функции CSS, поскольку она улучшит наши разработки и написание CSS. Мы не только проектируем размеры экрана, но и учитываем, как компоненты должны адаптироваться при изменении ширины их контейнера.

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

Рассмотрим следующий дизайн:

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

Для примера пользовательского интерфейса вот как мы можем разделить компоненты.

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

На следующем рисунке обратите внимание на то, как каждая вариация компонентов приложения имеет определенную ширину.

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

Более того, у нас может быть вариант компонента, который должен отображаться только в определенном контексте. Например, страница со списком событий. В таком случае важно четко понимать, где использовать этот вариант. Вопрос в том, как сказать дизайнерам, где им следует использовать эти компоненты?

Общение с разработчиками

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

Давайте применим это к компоненту статьи, который мы обсуждали ранее.

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

В сетке CSS мы можем указать браузеру, что мы хотим, чтобы столбцы расширялись, если их количество меньше ожидаемого, с помощью ключевого слова auto-fit. Это мощная функция, поскольку она может помочь нам показать разные варианты в одном и том же контексте. Рассмотрим следующий рисунок:

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

Избегайте сложностей при разработке адаптивных компонентов

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

В нем есть следующее:

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

Примеры использования контейнерных запросов CSS

Давайте рассмотрим некоторые варианты использования, которые можно реализовать с помощью контейнерных запросов CSS.

Список чата

Я видел эту закономерность в мессенджере Facebook. Список чата меняется в зависимости от ширины области просмотра. Мы можем реализовать это с помощью контейнерных запросов CSS.

Когда будет достаточно места, список расширится и отобразит имя каждого пользователя. Родительский элемент списка чата может быть элементом, размер которого изменяется динамически (например, с помощью модулей просмотра CSS или функций сравнения CSS).

Вот как мы можем реализовать это в CSS.

<div class="content"> <aside> <ul> <li> <img src="shadeed.jpg" alt="Ahmad Shadeed" /> <span class="name">Ahmad Shadeed</span> </li> </ul> </aside> <main> <h2>Main content</h2> </main>
</div>

.content { display: grid; grid-template-columns: 0.4fr 1fr;
} aside { contain: layout inline-size style;
} @container (min-width: 180px) { .name { display: block; }
}

Обратите внимание, что ширина стороны равна 0.4f, поэтому это динамическая ширина. С другой стороны, я добавил свойство contain. Затем, если ширина контейнера больше 180px, будет отображаться имя пользователя.

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

Обратите внимание, как метка элемента навигации перемещается на новую строку, когда контейнер (сбоку) маленький, и рядом со значком навигации, когда достаточно места.

Демо

Аккордеон

Шаблон аккордеона можно использовать для таких вещей, как FAQ. В некоторых случаях нам может потребоваться добавить список FQA на боковой панели или в небольшой области пользовательского интерфейса. Могут помочь контейнерные запросы!

Вот как мы можем реализовать описанное выше с помощью контейнерных запросов CSS.

@container (min-width: 180px) { .faq-title { display: flex; justify-content: space-between; font-size: 1.25rem; } .faq__icon { width: 60px; height: 60px; background-color: #4f96e7; }
}

Демо

Поле поиска

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

Список событий

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

Опять же, это тот же компонент, который адаптируется к своей родительской ширине. Разве это не круто? Для меня — да.

Биография автора

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

Кнопки обмена для социальных сетях

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

Когда компонент используется на боковой панели (слева), будет использоваться уменьшенная версия. Когда родительский элемент больше (например, основной раздел), будет использоваться полная версия. Спасибо за чтение

Автор: Ahmad Shadeed

Источник: ishadeed.com

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

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