Зачем использовать правило @supports
С ростом поддержки свойства определения поддержки функционала в CSS, под названием @supports
, я понял, что это могло бы быть клёвой идеей взять и немного углубиться в эту тему, рассказав про неё как можно больше информации.
Итак, вот быстрое описание того, что же свойство @supports
всё таки делает. По своей сути, @supports
работает как обычный медиа запрос, но детектит определенный функционал, вместо размеров viewport
, меида типов и т.д. Более менее, но это функция запроса. Использование @supports
в браузерах, которые поддерживают его (Все, кроме IE11 и ниже в этом направлении), дает нам возможность проверять, поддерживается ли определенный функционал браузером или нет. Если да, то последующие CSS правила будут применены, а если браузер не поддерживает какое-либо свойство, то оно будет проигнорировано без какого-либо вреда для верстки.
Теоретически, тут суть в том, чтобы дать нам возможность условно применять CSS, основываясь на поддержке его функционала самим браузером. У меня есть четкое представление об этом, но в поисках материала для этого поста, мне было немного сложно найти примеры для этого правила, которые реально заслуживают внимания. Давайте посмотрим на некоторые простые сценарии, которые пришли мне на ум в первую очередь.
@supports(display: flexbox)
Итак, ваш коллега только что отправил вам отличный дизайн. Хороший сеточный шаблон. Настало время размять свои CSS мускулы и применить немного flexbox
. Но нет! Аккаунт менеджеры только что сообщили вам, что вам нужна поддержка IE9. Хороший выстрел, ребята) Давайте разыграем сценарий, который бы имел место быть с @supports
. Давайте применим классический кейс с flexbox
. У вас есть несколько предметов (класс .thing
) c заголовком и описанием внутри. Текст описания варьируется по длине и вам надо убедиться в том, что все .thing
одной высоты, вне зависимости от длины контента. Может что-то типа этого нам подойдет?
.thing {
border: 2px solid #efefef;
margin: 10px;
padding: 20px;
// Fallback for IE9 if browser
// doesn't support flexbox.
float: left;
width: calc(33.333333% - 20px);
h2 {
color: #2b2b2b;
}
.description {
font-size: 1rem;
}
}
// Insert fanciness here
@supports (display: flexbox) {
.thing-wrapper {
align-items: stretch;
display: flex;
justify-content: center;
}
.thing {
flex: 0 1 33.333333%;
}
}
Отлично! Это выглядит как отличный пример использования @supports
. У нас есть процентная ширина и флоаты, примененные к .thing, а также фолбэк, если не поддерживается flexbox
!
Однако, давайте поиграем в адвоката дьявола и посмотрим, что же нас остановило от использования такого подхода:
.thing-wrapper {
align-items: stretch;
display: flex;
justify-content: center;
}
.thing {
border: 2px solid #efefef;
flex: 0 1 33.333333%;
margin: 10px;
padding: 20px;
//IE9 support
float: left;
width: calc(33.333333% - 60px);
h2 {
color: #2b2b2b;
}
.description {
font-size: 1rem;
}
}
.thing-wrapper
свойства будут проигнорированы, так как IE9 просто не воспримет их, а float
и width
свойства будут проигнорированы в новых браузерах из-за применения display: flex
. Сейчас, в организационном плане, возможно было бы хорошим тоном откинуть старые свойства, которые не поддерживают старые браузеры. Но в функциональном плане, выгода кажется слегка ограниченной.
Привет операторам
Давайте возьмем ещё один пример. Правило @support
также принимает несколько дополнительных операторов: not
, and
и or
. Вы можете связать эти операторы, чтобы улучшить свои результаты. Для примера, вы можете указать правилу @supports
запускаться когда браузер не поддерживает CSS свойство.
Давайте, к примеру, попробуем новые модные CSS переменные. Если браузер не поддерживает CSS переменные, то мы запустим CSS код, который компенсирует это.
@supports not (--color-1: #c0ffee) {
.coffee {
color: #c0ffee;
}
}
Простой пример, но он успешно делает свою работу. Что мы хотим тут сказать, так это то, что если браузер не поддерживает использование CSS переменных, то мы применяем цвет прямо к диву .coffee
. Это звучит очень круто, но сейчас нам надо рассмотреть примет ли браузер этот код, даже поддерживая правило @supports
. Если браузер не поддерживает правило @supports
, с которого мы начинаем, этот отрезок кода будет пропущен и наш div
.coffee
не получит стилизации, которую мы ему выдали.
Для уточнения, CSS переменные не поддерживаются в EDGE v14. Однако @supports
да. Следовательно, этот код будет работать! Что кстати великолепно, это определенно выглядит идеальным примером использования в этом случае.
Дополнительные сценарии
Постарайтесь остаться непредвзятым как я после этих двух кейсов, я пробежался по нескольким другим сценариям, которые я не стал так описывать, как предидущие два.
Я пытался найти некую выгоду в использовании правила для CSS keyframes
, которая закончилась также как и в первом примере c flexbox
. Я проверил новое свойство display: flow-root
, это аккуратное свойство, которое замещает уже застоявшийся clearfix
. Это был отличный кейс для оператора not, почти как и с нашим примером по теме CSS переменных. И в конце я проверил кейс с использованием CSS 3D трансформаций. И также как и с flexbox
примером, выявил те же проблемы.
TL;DR
И под конец, конечно же @supports
правило было бы фантастикой во былые времена, когда поддержка браузеров для разного CSS представляла собой невероятный беспорядок. Но сегодня, разработчики браузеров начинают поддерживать новые свойства чуть ли не одновременно. И даже если нет, то применяется не та логика, как в JavaScript. Если браузер не понимает CSS свойство, то он его пропускает и идет дальше. По факту, нет ощутимой выгоды в использовании @supports
, пока что. Есть определенно хорошие кейсы его применения и оператора not. Особенно в старых версиях Edge, который не поддерживает такие фишки, как CSS переменные. Однако, для меня, @supports
правило кажется скорее косметическим и дает ясный способ организации CSS свойств, которые необходимы для вашего нынешнего проекта, следуя его рекомендациям, которые могут не позволить вам использовать эти свойства в полной мере.