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

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

Что такое адаптивный веб-дизайн?

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

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

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

Модульный проект.

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

@media хак.

Веб-разработчики – это специалисты, которые умеют принимать нечто, созданное для одной цели, и использовать его для выполнения других задач. История развития интернета изобилует различными яркими примерами этого утверждения, и информационные запросы не являются исключением. Ян Сторм Тейлор представил множество интересных мыслей в статье «Особенности информационных запросов». Хаки необходимы для реализации желаемой функциональности, а также чтобы обеспечить поддержку старых браузеров. W3C заявляет о том, что «Благодаря использованию информационных запросов, различные представления могут быть приспособлены к определенному диапазону устройств вывода без изменения самого контента». В этом случае акцент делается на фразу «могут быть», поскольку способность сделать что-то, вовсе не означает, что это будет сделано … Но есть ли у нас другой выбор?

Компонентный запрос.

Давайте посмотрим, что представляет собой компонентный запрос (element query). Компонентный запрос похож на информационный запрос тем, что если условие выполнено, то будут применены необходимые CSS таблицы. Условия компонентного запроса (например, min-width, max-width, min-height и max-height) основаны на элементах, а не браузере. К сожалению, CSS еще не поддерживают компонентные запросы, но это не должно нам мешать в поиске новых стандартов.

Концептуальный пример.

Давайте рассмотрим следующий пример, в котором меню навигации должно стать видимыми при достижении минимальной ширины в 500 пикселей (представляем одно из многих потенциально возможных синтаксических решений):

nav (min-width: 500px) {
	display: block;
}

Сравните этот пример с информационным запросом, в котором видимость меню навигации зависит от ширины окна просмотра, а также требует учитывать заполнение и другие объявления родительских элементов:

@media all and (min-width: 520px) {
	nav {
		display: block;
	}
}

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

Проблемы: неправильные условия и организация циклов.

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

Рассмотрим следующие примеры.

После того, как элемент достигает 500 пикселей в ширину, его значение становится равным 200 пикселей, и в этот момент правило уже больше не будет применяться:

.element (min-width: 500px) {
	width: 200px;
}

После того, как ширина элемента достигнет � …

Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров