Контейнерные запросы CSS для дизайнеров — Блог о самом интересном.

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

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

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

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

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

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

Сейчас я покажу для вас наиболее подробный взор на дизайн и его варианты, чтоб пролить свет на делему, которую контейнерные запросы 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%; }

}

12345678910111213141516171819202122232425262728293031 .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 либо больше.

Топ-5 встроенных баз данных для приложений JavaScript

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

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

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

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

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

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

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

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

123456           

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

CSS .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 */ }

}

12345678910111213141516171819 .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.

  • »Ahmad Ahmad Shadeed

Main content

12345678910111213       

          

  •         »Ahmad        Ahmad Shadeed      
  •     

        

Main content

  

CSS .content { display: grid; grid-template-columns: 0.4fr 1fr;

}

aside { contain: layout inline-size style;

}

@container (min-width: 180px) { .name { display: block; }

}

1234567891011121314 .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.

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; }

}

12345678910111213 @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

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

Читайте нас в Telegram, VK, Yandex.Дзен

Источник

Вам также может понравиться