От автора: теперь, когда на горизонте появляются контейнерные запросы, нужны ли нам вообще медиа-запросы? Есть ли будущее, в котором мы будем создавать адаптивные интерфейсы полностью без них?
Итан, который ввел термин адаптивный веб-дизайн более десяти лет назад, недавно сказал, что макеты без медиа-запросов, безусловно, имеют определенные ограничения: Можем ли мы считать гибкий макет «отзывчивым», если он не использует никаких медиа-запросов, а использует только контейнерные запросы? […] Я бы ответил: да, безусловно.
На CSS-Tricks у Криса были похожие мысли. Он поставил задачу изучить, как и где медиа-запросы используются сегодня, и будут ли они по-прежнему необходимы в будущем: Распространенным вопросом, является следующий — если бы у нас были контейнерные запросы, использовали бы мы их для подавляющего большинства медиа-запросов, которые мы используем сегодня. Задача заключается в том, чтобы взглянуть на кодовую базу CSS свежим взглядом, зная, как в настоящее время работают запросы @container.
Я задумался и взглянул на некоторые из своих проектов — и да, большая часть того, где я использую @media сегодня, вероятно, может быть заменено на @container. Тем не менее, я придумал несколько сценариев, в которых, как мне кажется, медиа-запросы по-прежнему будут необходимы.
Для макета страницы
Хотя контейнерные запросы теоретически можно использовать для управления любым элементом, они действительно эффективны при применении к повторно используемым независимым компонентам. Канонический пример — компонент карты: автономный элемент пользовательского интерфейса, который можно разместить где угодно.
С другой стороны, макеты страниц, на мой взгляд, лучше подходят для медиа-запросов. Макеты страниц обычно находятся на самом верхнем уровне DOM, а не вложены в другой контейнер. Я никогда не сталкивался со случаем, когда макет главной страницы должен был адаптироваться к любому другому контексту, кроме области просмотра.
.layout { display: grid;
}
@media (min-width: 60em) { .layout { grid-template-rows: 4rem 1fr auto; grid-template-columns: 25% 1fr; grid-template-areas: "header header" "sidebar main" "footer footer"; }
}Для глобальных токенов
Еще один хороший вариант использования медиа-запросов — это установка глобальных токенов дизайна, таких как интервалы или размеры шрифта. Благодаря пользовательским свойствам CSS теперь намного проще осуществлять точный контроль над глобальными стилями для различных устройств.
Например, вы можете захотеть, чтобы на большом телевизоре был текст большего размера и больше пробелов, чем на экране мобильного телефона. Экран большего размера означает, что глаза пользователя будут находится физически дальше.
Здесь имеет смысл использовать только медиа-запрос, поскольку причиной изменения является размер самого устройства, а не ширина какого-либо конкретного элемента.
:root { /* Font Sizes */ --font-size-headline-l: 1.875rem; --font-size-headline-m: 1.75rem; --font-size-headline-s: 1.5rem; --font-size-copy-l: 1.125rem; --font-size-copy-s: 0.875rem; /* Global Spacing */ --spacing-x: 1rem; --spacing-y: 1rem;
}
@media (min-width: 48em) { :root { --font-size-headline-l: 2.5rem; --font-size-headline-m: 2rem; --font-size-headline-s: 1.75rem; --font-size-copy-l: 1.25rem; --font-size-copy-s: 1rem; --spacing-x: 2rem; --spacing-y: 2rem; }
}Для пользовательских предпочтений и фактических «медиа» запросов
Размеры экрана — не единственное, что мы можем определить с помощью медиа-запросов. Спецификация Media Queries Level 4 Spec (уровень 5 в настоящее время является рабочим проектом) перечисляет множество различных запросов, связанных с предпочтениями пользователя, например:
prefers-reduced-motion
prefers-contrast
prefers-reduced-transparency
prefers-color-scheme
inverted-colors
и другие
Мы можем использовать их, чтобы лучше адаптировать связь с конкретными потребностями текущего пользователя. Другие медиа-запросы позволяют выполнять микрооптимизацию на основе метода ввода устройства (например, касания или клика мыши):
/* fine pointers (mouse) can hit smaller checkboxes */
@media (pointer: fine) { input[type="checkbox"] { width: 1rem; height: 1rem; border-width: 1px; border-color: blue; }
} /* coarse pointers (touch) need larger hit areas */
@media (pointer: coarse) { input[type="checkbox"] { width: 2rem; height: 2rem; border-width: 2px; }
}Наконец, запросы на подобе @media print, никуда не пропадают. Обсуждаются экспериментальные идеи новых медиа-запросов, например, для «складывающихся» устройств:
:root { --sidebar-width: 5rem;
}
/* if there's a single, vertical fold in the device's screen, expand the sidebar width to cover the entire left side. */
@media (spanning: single-fold-vertical) { :root { --sidebar-width: env(fold-left); }
}
main { display: grid; grid-template-columns: var(--sidebar-width) 1fr;
}Для компонентов, привязанных к окну
Компоненты, внутри контейнера, не должны заботиться о своих внешних контейнерах. Некоторые элементы пользовательского интерфейса прикреплены к самому окну просмотра и обычно ориентированы вдоль края экрана.
Взгляните, например, на вкладку Twitter «Сообщения» внизу экрана. Соответствующим контейнером является окно, поэтому имеет смысл использовать здесь медиа-запрос и применять position:fixed только в точке останова.
Для высоты
Текущая реализация @container позволяет запрашивать только ширину элемента (его «встроенную» ось), но не его высоту.
Мириам говорит, что это можно запросить высоту контейнеров, при условии , что они определяются как size вместо inline-size.
Корректировка стиля по отношению к ширине, вероятно, в любом случае является основным вариантом использования большинства элементов пользовательского интерфейса, но все же есть случаи, когда высота экрана является проблемой. Вот пример:
.hero { display:flex; flex-direction: column; height: 100vh;
}
/* if the screen is really tall, don't fill all of it */
@media (min-height: 60em) { .hero { height: 75vh; }
}Комбинируйте контейнерные запросы и медиа-запросы
Хотя я думаю, что контейнерные запросы в конечном итоге заменят большую часть «низкоуровневой» гибкой логики, все еще есть много хороших сценариев использования надежных медиа-запросов.
Сочетание обоих методов, вероятно, будет лучшим вариантом. @media может обрабатывать большие изображения, пользовательские предпочтения и глобальные стили а @container позаботится обо всех тонких настройках самих компонентов.
Автор: Max Böck
Источник: mxb.dev
Редакция: Команда webformyself.
Читайте нас в Telegram, VK, Яндекс.Дзен