18.10.2021

Введение в контейнерные запросы CSS

Введение в контейнерные запросы CSS

От создателя: прототип долгожданных контейнерных запросов CSS добавлен в Chrome Canary и доступен для тестов. Давайте рассмотрим, какую проблему они решают, узнаем, как работают, и поглядим, как они дополняют существующие функции CSS.

В текущее время контейнерные запросы можно использовать в Chrome Canary, выполнив поиск и включив их в chrome://flags. (Будет нужно перезагрузка браузера).

Введение в контейнерные запросы CSS

Просмотр результатов поиска в Chrome Canary на экране опций chrome: // flags, на котором отображается элемент «Включить контейнерные запросы CSS» со статусом «Включено».

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

Какую делему решают контейнерные запросы CSS?

Практически 11 лет назад Итан Маркотт познакомил нас с концепцией адаптивного дизайна. Центральным элементом этой идеи была доступность медиа-запросов CSS, которые позволяли устанавливать разные правила в зависимости от размера области просмотра. IPhone был представлен 3-мя годами ранее, и мы все пробовали понять, как работать в этом новеньком мире, где нужно учитывать как размеры экрана мобильных устройств, так и размеры экрана монитора компьютера (которые в среднем были намного меньше, чем сейчас).

До и даже после внедрения адаптивного дизайна многие компании решали делему изменения макета в зависимости от размера экрана, предоставляя совсем разные сайты, часто на поддомене «m». Адаптивный дизайн и медиа-запросы открыли огромное количество других решений для макетов и многолетнюю разработку передовых способов реагирования на размеры области просмотра. Не считая того, популярность таких фреймворков, как Bootstrap, выросла в основном благодаря предоставлению разработчикам адаптивных систем сетки.

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

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

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

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

Контейнерные запросы выводят нас за рамки рассмотрения только области просмотра и позволяют хоть какому компоненту или элементу реагировать на определенную ширину контейнера.

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

Скоро мы рассмотрим другие примеры, но поначалу давайте узнаем, как создать контейнерный запрос!

Начало работы с контейнерными запросами CSS

1-ое, что нужно знать о контейнерных запросах CSS, это то, что «контейнеры» — это запрашиваемые элементы , а правила снутри запросов контейнера влияют только на потомков контейнера. Другими словами — вы сможете определить main как контейнер, или, может быть, article или даже как элементы перечня. Затем контейнерные запросы позволят определить правила того, как элементы в их меняются в зависимости от размера контейнера.

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

Свойство contain воспринимает одно или несколько значений, и имеет все огромную поддержку для начального сочетания размеров макета. Значение layout делает контекст форматирования блока , который будет содержать нужные поля, чтобы его содержимое не оказывало влияние на содержимое в другом контейнере. Значение size просит установки явных значений высоты и ширины либо получения размеров извне, например, от родительских частей сетки, поскольку с этим значением элемент больше не будет определять свои размеры от собственных дочерних элементов.

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

Предложение контейнерного запроса создателя Мириам Сюзанной определяет новое значение inline-size. Принимая во внимание, что size употребляют для установки значений в обоих направлениях (ширина и высота), значение inline-size — основано на определении ширины.

Мириам подразумевает, что чаще всего авторы CSS пробуют органичить элементы на основе ширины. Меж тем, высота может быть внутренней — другими словами, возрастать или уменьшаться в зависимости от ограниченного элемента. Таким образом, inline-size считается одноосным ограничением. И это значение доступно в Chrome Canary и позволяет нам начать экспериментировать с контейнерными запросами.

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

CSS

Нам необходимо было включить значения layout и inline-size для удачной работы контейнерных запросов. Кроме того, Мириам также порекомендовала добавить style чтобы избежать потенциального нескончаемого цикла при настройке свойств, таких как счетчики, которые имеют возможность запускать изменения за пределами контейнера и оказывать влияние на его размер, вызывая цикл конфигурации размера.

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

Когда вы используете контейнерный запрос, вы изменяете не сам контейнер, а элементы снутри этого контейнера.
Использование inline-size делает ограничение контекста для элементов в этом контейнере. Запрошенный элемент будет использовать собственного ближайшего предка с примененным ограничением. Это принципиально, потому что можно вкладывать контейнеры. Потому, если вы не знаете, что это за контейнер, либо создаете вложенный контейнер, результаты для потомков имеют возможность измениться.

Итак, как на самом деле смотрится контейнерный запрос? Синтаксис будет знаком из медиа-запросов, так как они начинаются с @container, а потом указывается необходимое значение, например (min-width: 300px). Представим, мы разместили наш класс container в <main> элементе, и он содержит несколько <articles>:

Сейчас мы можем настроить контейнерный запрос для конфигурации articles и любого из их потомков, который будет основан на ширине main, так как это содержащий элемент. До сих пор в собственных экспериментах я счел полезным думать об этом как о концепции «поначалу мобильные», за исключением того, что в данном случае это «поначалу самый узкий контейнер». Это означает, что я поначалу определю стили для моего наименьшего ожидаемого контейнера, а потом буду использовать контейнерные запросы для конфигурации стилей по мере увеличения контейнера.

CSS

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

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

Если мы настроим наш контейнер main и определим гибкую сетку, чтоб статьи реагировали как гибкие дочерние элементы, мы столкнемся с некой проблемой:

CSS

Вы сможете ожидать, что, когда ширина статьи меньше, чем 60ch, она востребует уменьшенных отступов и размера шрифта. Но, поскольку статьи являются прямыми дочерними элементами main, а main являются единственным контекстом ограничения, статьи не поменяются, пока ширина main не станет меньше ширины контейнерного запроса. Мы столкнулись бы с аналогичной неувязкой, если бы использовали CSS-сетку для размещения статей.

Чтоб решить эту проблему, в каждую статью нужно добавить ограничивающий элемент, чтобы правильно запрашивать ширину гибкого элемента. Это поэтому, что элемент main больше не представляет ширину элемента. В этом случае самое резвое решение — добавить элементы div в наш класс container вокруг каждой статьи.

Нам также необходимо будет переключить наше определение flex с article на новое div, в которое мы также добавили класс article для простоты написания нашего правила:

CSS

В итоге, последняя статья охватывает всю ширину и будет иметь стили огромных контейнеров. Вот CodePen этого примера контейнерных запросов для дочерних частей Flexbox (напоминание для просмотра в Chrome Canary с включенными контейнерными запросами, как обозначено в начале!).

Введение в контейнерные запросы CSS

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

Мы тоже обусловили main как контейнер. Это означает, что мы можем добавлять стили для класса .article, но они будут зависеть от ширины main, а не от самих. Я думаю, что возможность иметь правила снутри контейнерных запросов, отвечающих за несколько уровней контейнеров, вызовет самую большую путаницу при первоначальной реализации и следующей оценке и совместном использовании таблиц стилей.

В ближнем будущем обновления браузера DevTools, безусловно, посодействуют внести изменения в DOM, которые изменят эти типы отношений меж элементами и контейнерами, которые они имеют возможность запрашивать. Возможно, новая передовая практика будет заключаться в том, чтоб запрашивать только один уровень выше в блоке @container и заставлять наследников иметь собственный контейнер, чтобы уменьшить возможность негативного воздействия. Компромисс — это возможность большего количества частей DOM, как мы видели в нашем примере статьи, и, как следует, увеличение семантики.

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

Правила выбора элемента контейнера

Ранее я упоминал, что сам контейнер не может быть оформлен в рамках запроса контейнера (если только он не является вложенным контейнером и не отвечает на запрос контейнера-предка). Но контейнер можно использовать как часть селектора CSS для его дочерних частей.

Почему это важно? Это позволяет сохранить доступ к псевдоклассам и селекторам CSS, которые имеют возможность возникнуть в контейнере, например :nth-child.

В нашем примере, если мы желаем добавить границу odd к каждой статье, мы можем написать последующее:

CSS

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

Пример для обучения: обновление тизеров статей на SmashingMagazine

Если вы посетите профиль создателя здесь на Smashing (например, мой) и измените размер собственного браузера, вы заметите, что расположение частей тизера статьи меняется в зависимости от ширины области просмотра.

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

Введение в контейнерные запросы CSS

Снимок экрана с 3-мя настройками макета, описанными в предыдущем абзаце.

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

Для этой демонстрации я использовал мало необходимые существующие стили из Smashing и сделал только одну модификацию имеющейся модели DOM, которая заключалась в перемещении заголовка в компонент header (и превращении его в h2).

Вот сокращенный кусок структуры DOM статьи, чтобы показать элементы, которые мы желаем переупорядочить (оригинальные имена классов сохранены):

Представим, что это прямые потомки, main и определим main как наш контейнер:

CSS

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

CSS

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

До этого чем мы продолжим, мы должны также сделать шаблон сетки для header, чтобы иметь возможность передвигаться между аватаром, именем автора и заголовоком. Мы добавим в правило .article—post header:

CSS

Если вы не знакомы с grid-template-areas — то мы тут делаем так, чтобы в верхней строке был один столбец для аватара и один для имени. Потом во второй строке мы планируем, чтоб заголовок охватывал оба этих столбца, которые мы определяем, используя одно и то же имя два раза.

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

Теперь нам необходимо обязательно явно разместить связанные элементы в этих областях:

CSS

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

CSS

Примечание: Safari не так давно завершил поддержку gap для flexbox, то есть сейчас он поддерживается для всех современных браузеров!

Введение в контейнерные запросы CSS

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

Сейчас мы можем перейти к первому из 2-ух контейнерных запросов, чтобы создать представление среднего размера. Давайте воспользуемся возможностью создавать запросы, относящиеся к шрифту, и основывать их на превышении контейнером 60ch. На мой взор, создание содержимого в зависимости от длины строчки — это практичный способ управлять переменами ширины контейнера. Тем не менее, вы, непременно, можете использовать пиксели, rems, ems и может быть, другие опции в будущем.

Для среднего размера нам необходимо настроить шаблоны сетки заголовка и общей статьи:

CSS

При таковой ширине мы хотим, чтобы аватар отображался в отдельной колонке слева от остального содержимого. Для этого в шаблоне сетки он назначается первому столбцу обеих строк, а потом смещается имя в строку один столбца два, а заголовок в строчку два столбца два. Аватар также должен быть выровнен по верхнему краю, его можно отрегулировать с помощью align-items: start.

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

Введение в контейнерные запросы CSS

Макет запроса контейнера среднего размера с зрительно отображаемым аватаром в собственном столбце слева от остального содержимого.

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

CSS

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

Смотря на окончательную версию этой страницы, мы лицезреем, что статья не занимает 100% ширины макета Smashing. Чтоб сохранить такое расположение, внутри grid-auto-columns мы используем функцию fit-content, которую можно читать как: «расти до внутренней наибольшей ширины содержимого, но не больше, чем предоставленное значение». Итак, мы говорим, что столбец может расти, но не превосходить 70ch. Это не предотвращает его сжатие, потому столбец также остается чувствительным к доступному месту.

Следуя за столбцом content, мы определяем ширину столбца статистики auto. Это значит, что ему будет разрешено занимать внутреннее место, необходимое для размещения его содержимого.

Введение в контейнерные запросы CSS

При самом большом расположении компонентов статьи время чтения и статистика комментариев передвигаются вправо от основного содержания, а содержание статьи занимает наибольшее горизонтальное место.

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

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

Потом мы назначим .article—post-container контейнером:

CSS

Сейчас, если мы создадим макет сетки, как мы это делали во вводном примере, мы разместим одну статью над сетью и две внутри ее. Вот полный CodePen этой демонстрации, включая гибкую сетку:

Способности и предостережения при использовании контейнерных запросов

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

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

Адаптивная типоргафика

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

Если спецификация получит контейнерную единицу (о которой мы скоро поговорим), мы сможем достичь внутренней типографики. Но даже с текущей спецификацией мы можем найти адаптивную типографику, изменив значение font-size для разных размеров содержащихся элементов. Фактически, мы только что сделали это в примере со статьями Smashing Magazine.

Несмотря на то что это интересно с точки зрения дизайна и верстки, оно просит той же осторожности, что и имеющиеся решения для гибкой типографии. Для доступности юзер должен иметь возможность масштабировать макет и наращивать его font-size до 200% от начального размера. Если вы создадите решение, которое резко уменьшает размер шрифта в наименьших контейнерах — который может быть вычисленным размером при масштабировании — юзер никогда не сможет добиться увеличения базы font-size на 200%. Я уверен, что мы увидим больше советов и решений по этому поводу, когда мы больше познакомимся с контейнерными запросами!

Изменение отображаемых значений

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

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

Возможные сценарии включают:

изменение формы подписки на новостную рассылку с горизонтальной на многослойную;

создание чередующихся разделов шаблона сетки;

изменение соотношения сторон изображений и их положения по сопоставлению с соответствующим контентом;

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

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

Отображение, скрытие и перестановка

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

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

Разрабатывать один раз и развертывать где угодно

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

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

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

К примеру, рассмотрим компонент карты, который предполагает, что его font-size должен поменяться. Но в конкретном случае фактическое количество знаков было намного больше или намного короче, и эти правила были неоптимальными. Согласиться с этим, возможно, будет проще, чем пытаться переопределить каждый отдельный запрос контейнера, который был прикреплен.

Что может поменяться в спецификации

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

Я уже упоминал о 2-ух ключевых проблемах, которые еще предстоит разрешить:

# 6178: Как разрешить делему с @container, если не определены контейнеры-предки?

# 5989: Какие способности контейнера можно запрашивать?

Огромное значение и влияние имеют:

Должен ли быть новый синтаксис для сотворения запрашиваемых контейнеров? (# 6174). Первоначальный выпуск от Мириам предлагает два варианта: или нового набора выделенных значений contain, или, возможно, вызываемого совершенно нового свойства containment. Если какое-либо из этих конфигураций произойдет на этапе прототипа, значения, показанные в начале этой статьи, имеют возможность больше не работать. Итак, еще раз обратите внимание, что экспериментировать — это здорово, но имейте в виду, что все будет продолжать изменяться!

Также представляет интерес возможность возникновения новых контейнерных единиц, отслеживаемых в:

Единицы «ширина контейнера» и «высота контейнера» (# 5888). Это могло бы открыть собственное решение CSS для внутренней типографики, посреди прочего, что-то вроде: font-size: clamp(1.5rem, 1rem + 4cw, 3rem)(где cw- заполнитель для неопределенной в актуальный момент единицы, которая может представлять ширину контейнера).

По материалам webformyself.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *