• 7 минут чтения

• Кодирование, CSS, Адаптивный дизайн

• Поделись ТвиттерЛинкедин

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

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

Дальнейшее чтение на SmashingMag:

• Picturefill 2.0: адаптивные изображения и идеальный полифилл
• Как я закончил с запросами элементов
• Список для чтения Flexbox: методы и инструменты

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

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

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

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

Модульная конструкция

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

Взлом @media

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

Запрос элемента

Знакомство с элементом запроса. Элементный запрос похож на медиа-запрос в том смысле, что при выполнении условия будет применен некоторый 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;
}

Как только ширина элемента достигнет 31 250 em, размер его шрифта уменьшится, что изменит определение единицы em:

.element (min-width: 31.250em) {
    font-size: 0.75em;
}

Как только ширина контейнера достигает 450 пикселей, размер его дочернего элемента изменяется на 400 пикселей, что уменьшит размер контейнера:

.container { float: left; }
.child { width: 500px; }
.container (min-width: 450px) > .child {
    width: 400px;
}

Есть много других подобных примеров, но вы поняли: запросы к элементам не так просты, как мы надеялись.

Полифилл запроса элемента

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

Сценарий полифилла elementQuery доступен на GitHub, и вы можете использовать его, разветвлять и вносить свой вклад.

Синтаксис селектора

Синтаксис, используемый в предыдущих примерах, вызывал ограничения, поэтому я обновил полифил, чтобы он поддерживал синтаксис селектора атрибутов. То ~= Селектор атрибутов проверяет, содержится ли значение в списке, разделенном пробелами (поддерживается в современных браузерах выше Internet Explorer 6).

В следующих примерах показаны правила CSS с использованием синтаксиса, необходимого для полифилла elementQuery.

Это правило запрашивает само себя по одному условию:

header[min-width~="500px"] {
    background-color: #eee;
}

Это правило запрашивает само себя для нескольких условий:

header[min-width~="500px"][max-width~="800px"] {
    background-color: #eee;
}

Это правило запрашивает у родителя условие:

header[min-width~="31.250em"] nav {
    clear: both;
}

Как это работает

К сожалению, для полифилла elementQuery требуется JavaScript и механизм выбора Sizzle (который встроен в jQuery). Когда объектная модель документа (DOM) готова, elementQuery сканирует document.styleSheets коллекция для любых правил CSS, использующих elementQuery. Когда он находит совпадение, он извлекает следующую информацию:

• Селектор. Такие как header, ul > li.class
• Тип запроса min-width, max-width, min-height, max-height
• Значение запроса. Такие как 500px, 31.250em

Затем elementQuery использует эту информацию для добавления или удаления атрибутов элементов, соответствующих данному селектору и условию запроса.

Расширенная поддержка

Большинство браузеров, за исключением Internet Explorer, не предоставляют доступ к содержимому междоменных таблиц стилей, что вызывает проблемы, когда файлы CSS обслуживаются из сети доставки контента. Кроме того, синтаксический анализ таблиц стилей требует времени (хотя и небольшого). Итак, я создал две ветки для elementQuery: master и prod. Ветка master включает в себя код для извлечения необходимой информации elementQuery (селектор, тип запроса, значение запроса), а также предоставляет selectors() функция экспорта информации. Ветвь prod требует, чтобы информация была объявлена ​​в JavaScript, что позволяет избежать проблем с междоменными файлами и времени, необходимого для синтаксического анализа таблиц стилей.

Вот пример того, как экспортировать информацию elementQuery с помощью ветки master:

console.log(JSON.stringify(elementQuery.selectors()));

А вот пример того, как импортировать информацию elementQuery с помощью ветки prod:

elementQuery({"header":{"min-width":["500px","31.250em"],"max-width":["800px"]}});

Рабочие примеры

Я собрал несколько рабочих примеров на CodePen (используя ветку master), с которыми вы можете поэкспериментировать или разветвить. Я хотел бы увидеть, какие другие примеры создают люди (которые, вероятно, будут намного круче, чем мои). Просто не забудьте пометить их тегом #elementquery, чтобы другие могли извлечь из этого пользу.

• Сетка: вложенные элементы
• Меню: elementQuery на основе ширины
• Цитата: elementQuery на основе высоты

Будь креативным

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

• Просмотрите elementQuery на GitHub.

Дальнейшее чтение

• «Значения Em в JavaScript», Тайсон Матанич.
• «Работа с отсутствием запросов элементов», Filament Group
• «Элементные запросы», Таб Аткинс мл.

(Источник изображения на первой странице: Look Beyond Common Media Query Breakpoints)

(аль)