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

• Мобильный, адаптивный дизайн

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

Этот пост должен называться «Опережая себя». «…Через несколько лет», на самом деле. Вот в чем дело: в то время, когда я пишу это, в начале 2013 года, не было способа точного проектирования для Интернета с использованием физических единиц, и не будет в течение очень долгого времени. Но есть способ спроектировать, зная физические характеристики устройства — или, по крайней мере, будет в самом ближайшем будущем.

Он называется «медиа-запрос разрешения» и уже некоторое время присутствует в спецификации медиа-запросов. Однако, хотя это было в спецификации, это не значит, что кто-то еще реализовал это. К счастью, WebKit лидирует и настаивает на реализации этой функции. Итак, как именно мы будем использовать эту изящную маленькую функцию? Вот как.

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

• Отзывчивый веб-дизайн: что это такое и как его использовать
• Методы изящного снижения качества медиа-запросов
• Автоматически управляемые изображения? Ну вот.
• Логические контрольные точки для адаптивного дизайна

Тонкая грань между запросами

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

@media (min-resolution: 250dpi) {

}

в настоящее время имеет только одно полезное применение: замена изображений с низким разрешением на изображения с высоким разрешением. Я пытался представить себе другие варианты использования, и, насколько я могу судить, их просто нет. Но разрешение — это не то, что нас, как веб-дизайнеров, действительно интересует. Поскольку мы разрабатываем дизайн для людей, не должны ли мы думать о физической стороне потребления данных человеком и проектирования с использованием такого рода показателей? И в идеальном мире мы могли бы просто сказать width: 1in и иметь элемент шириной один дюйм, независимо от устройства. К сожалению, мы живем в цифровом мире, в котором физические и цифровые пиксели не совпадают. Нам нужно что-то, чтобы преодолеть разрыв. Это что-то является медиа-запросом разрешения.

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

Давайте сравним два объявления медиа-запроса:

@media (min-resolution: 341dpi) and (min-width: 767px) > {

}

и

@media (max-resolution: 131dpi) and (min-width: 767px) > {

}

На первый взгляд, это не кажется большим разделением, не так ли? Неправильный. Цифры, которые я использовал, относятся к HTC Windows Phone 8X (первый фрагмент) и iPad 2 (второй фрагмент). Используя запрос разрешения, можно в основном отделить физически маленькие устройства от больших устройств.

В настоящее время запрос, который выглядит как @media (min-width: 767px){ } повлияет как на HTC, так и на iPad, без какой-либо другой возможности разделения, поскольку оба имеют разрешение шириной 768 пикселей. На самом деле, iPad имеет более низкое разрешение — 1024 × 768, тогда как HTC — 1280 × 768. Если вы еще не поняли, проблема всего этого в том, что iPad — это 10-дюймовое устройство, а HTC — 4,3-дюймовый. Это меньше половины физического размера!

Используя мультимедийный запрос разрешения вместе с запросом ширины, мы можем различать физически маленькие и большие устройства, чтобы соответствующим образом настроить элементы дизайна и макеты. Хотя, как упоминалось выше, разрешение экрана не В самом деле то, что нас интересует, так как мы используем логические точки останова в адаптивном дизайне, это является полезно знать, отображается ли сайт на маленьком или большом физическом дисплее — например, чтобы увеличить размер шрифта или изменить расположение элементов дизайна в макете. Но где провести грань между малым и большим? Все просто, мы не можем. Каждый из нас должен провести границу, возможно, в зависимости от проекта, между «Это маленькое устройство» и «Это большое устройство». Что касается приблизительных цифр, я сделал несколько расчетов и разработал теорему, которая должна дать вам более четкое представление о том, как это работает.

Неисчерпывающая теорема исследования физического размера (PSINET)

Вот теория: в комбинированном запросе, если отношение между меньшей шириной и высотой и разрешением, называемое ПСИНЕТ оценка, выше, чем 5, то результат попадает в категорию физически большого устройства. Если полученное число меньше 5, то это физически маленькое устройство. Устройства, набравшие очень близкое к 5 баллу, считаются средними, близкими к физическому размеру листа бумаги формата А4 (21 × 29,7 см).

Вот неполный список устройств для проверки приведенной выше формулы. Я перечислил оценку каждого устройства в соответствии с формулой, а также его размер по диагонали, разрешение и плотность, а также оценку PSINET.

Физически большие устройства

Физически маленькие устройства

Устройства среднего размера

Является ли этот метод определения размера устройства надежным? Вряд ли — вот почему это теорема. Он основан на основательных рассуждениях и эмпирических данных и получен с использованием научного метода, но это не правило, закон или аксиома. Возьмите его с щепоткой соли (или, еще лучше, с грузовиком NaCl) и очистите его. Это теорема, предложение, о котором следует помнить в будущем, когда медиа-запрос разрешения и наша работа с ним станут опорой Сети.

Нарушение теоремы

Как любой уважающий себя последователь научного метода, я пытался сломать собственную теорему. Таким образом, я представил уродливое устройство, 2 дюйма в длину и 20 дюймов в ширину, с размером диагонали 20,09 дюйма, с дисплеем 240 × 40 пикселей, дающим разрешение всего 11,94 PPI. Он получает оценку PSINET 2,01, что хорошо относит его к категории небольших устройств, несмотря на то, что его длина составляет почти полметра. Причина проста: это размер в 2 дюйма. Поскольку показатель PSINET игнорирует большую часть физической ширины и высоты устройства, чем больше разница между этими двумя размерами, тем менее точным будет показатель PSINET. Конечно, это чудовищное устройство вряд ли когда-нибудь станет реальностью, но стоит понять причины, по которым оно может нарушить теорему.

Реальные приложения

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

Введите Enquire.js. Для тех из вас, кто не слышал об этом, это очень хорошая библиотека JavaScript, которая помогает вам выполнять определенные сценарии при сопоставлении медиа-запросов.

Мы могли бы использовать Enquire.js или даже просто window.matchMedia, который является нативным методом JavaScript, чтобы различать пользователей мобильных устройств, планшетов и компьютеров гораздо надежнее, чем при использовании только запросов ширины. Вот не очень вежливый пример использования Enquire.js:

enquire.register("screen and max-resolution: 150dpi and max-width: 300px", function() {
    alert('My, what a small screen you have there, Grandma!')
});

Сочетание типов медиа-запросов с CSS и использование JavaScript-библиотеки с учетом разрешения — это как раз правильная формула, которая даст нам реальный контроль над тем, что я называю «физической сетью». Представьте себе, что вы можете увидеть бесценную скульптуру, расположенную в музее на другом конце Земли, в масштабе 1:1 на любом устройстве или купить обручальное кольцо в Интернете и точно увидеть, насколько велик этот 24-каратный бриллиант. Реальные приложения, каламбур, почти бесконечны.

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

(аль)