Автор: Этан Мэркотт (ETHAN MARCOTTE)
Иллюстрации: Кевин Корнэлл (KEVIN CORNELL)
Оригинал: http://www.alistapart.com/articles/responsive-web-design/ (25 мая 2010)
Контроль над результатом, который есть у дизайнеров в полиграфии, и о котором они часто мечтают в вебе, — это просто результат фиксированного размера печатной страницы. Мы должны принять тот факт, что в вебе нет таких ограничений, и проектировать с учетом этой гибкости. Но для начала мы должны «принять изменчивую природу вещей».
— Джон Олсопп, «Дао веб-дизайна»
Английский архитектор Кристофер Врэн однажды пошутил, что его область деятельности «стремится к бесконечности». Юмор подобной формулировки в том, что в отличии от веба, который не смотрит дальше следующей недели, архитектура — это дисциплина, для которой постоянство является определяющей характеристикой.
Фундамент здания задает форму основанию. Основание определяет, каким будет твердый каркас здания. Каркас, в свою очередь, задает внешний облик фасада. Каждый этап архитектурного проектирования все меньше и меньше поддается изменениям по сравнению с предыдущим. Творческие решения определяют довольно точные формы физического пространства и задают пути перемещения по нему людей на протяжении десятилетий или даже веков.
Проектировать для веба — совершенно другой вопрос. Результат нашей работы примечателен небольшим сроком жизни. Как правило, он модернизируется или полностью обновляется через год иди два. Противоречивые размеры окон браузеров, многообразные разрешения экранов, специфические настройки пользователей и шрифты, которые у них установлены, — это далеко не полный перечень вещей, с которыми нам надо договориться о гармонии, когда мы запускаем проект в жизнь. Стоит отметить, что за прошедшие годы мы стали в этом довольно искусны.
Но жизнь меняется, возможно, даже быстрее, чем мы бы этого хотели. Ожидается, что мобильный интернет обгонит по популярности выход в интернет с обычного компьютера в течении ближайших трех—пяти лет. Две из трех самых популярных игровых приставок уже имеют веб-браузеры (причем один из них весьма не плох). Мы проектируем для мышек и клавиатур, для Т9-клавиатур, для игровых джойстиков и устройств с сенсорными экранами. Проще говоря, мы находимся лицом к лицу с таким множеством устройств, способов ввода данных и браузеров, какого раньше никогда не было.
В последние годы я часто встречаю компании, которым нужен «сайт под iPhone» как дополнение к основному проекту. Это интересное словосочетание. По сути, оно характеризует мобильный WebKit и как качественный браузер, и как мощный пример выхода бизнес-мышления за рамки обычных настольных компьютеров.
Однако, мне кажется, что мы, будучи дизайнерами, слишком любим комфорт, который дают такие четкие ограничения, поскольку в подобных случаях они позволяют легко разложить по полочкам все стоящие перед нами проблемы.
Мы можем изолировать мобильные версии сайтов по разным поддоменам, отдельно огородить «сайты не под iPhone». Но что дальше? «Сайт под iPad»? «Сайт под N90»? Можем ли мы на самом деле продолжать брать на себя обязательства по поддержке каждого нового устройства с уникальными параметрами взаимодействия?
В определенный момент начинает казаться, что это игра в «дурака» с самим собой. И как же нам и нашим проектам не проиграть?
Гибкая основа
Давайте рассмотрим пример. Я сверстал эту страницу для вымышленного журнала. Ее простая двухколоночная разметка реализована при помощи резиновой верстки с добавлением небольшого числа масштабируемых картинок.
Мне, как стороннику резиновой верстки, давно кажется, что она имеет больший запас прочности на будущее просто потому, что в ней учтена неопределенность. В какой-то мере это так и есть: резиновая верстка не делает предположений о ширине окна браузера и прекрасно адаптируется под устройства и с портретной, и с альбомной ориентацией страницы.
Огромные изображения огромны.
Наша верстка, несмотря на то, что она резиновая,
не реагирует должным образом на изменение разрешения или размера области просмотра.
Но в реальной жизни дизайн страницы (фиксированный или резиновый — не важно) вынужден плавно масштабироваться вне контекста, для которого он был спроектирован изначально.
Наш пример прекрасно ведет себя при изменении размеров окна браузера, однако, при низком разрешении начинают проявляться некоторые его недочеты. Если размер области просмотра сделать менее, чем 800×600 пикселей, то иллюстрация за логотипом обрезается, текст в пунктах меню может переноситься на другую строку неподобающим образом, а изображения с портретами становятся слишком малы и неразборчивы.
И подобные проблемы происходят не только при низком разрешении: если просматривать эту страницу на широкоформатном мониторе, то изображения увеличиваются до громоздких размеров, заслоняя и вытесняя собой весь окружающий контент.
Проще говоря, наша резиновая верстка достаточно хорошо работает в условиях, для которого она создавалась, но не оптимизирована для ситуаций, связанных с выходом за определенные рамки.
Начинаем реагировать
Молодая дисциплина, называемая «адаптивной архитектурой», еще совсем недавно поставила вопрос о том, как физическое пространство может реагировать на присутствие проходящих через него людей.
Используя комбинацию встроенной робототехники и гибких материалов, архитекторы экспериментируют с художественными инсталляциями и интерактивными стенами, которые гнутся и расширяются, когда человек подходит к ним. Датчики движения могут быть соединены с системой климат-контроля для управления температурой и освещенностью комнаты по мере того, как она заполняется людьми. Некоторые компании уже производят «умное стекло», которое может автоматически становиться непрозрачным, когда количество присутствующих в комнате достигает определенного уровня.
В своей книге «Интерактивная архитектура» Майкл Фокс (MICHAEL FOX) и Майлс Кемп (MILES KEMP) описывают этот более гибкий способ организации пространства как «многозвенную систему, к которой кто-то подключается для общения; постоянный и конструктивный обмен информацией».
Я выделил эту часть цитаты курсивом, поскольку считаю, что в ней заключается тонкое, но довольно важное отличие. Вместо того, чтобы создавать статичные и неизменяемые пространства, которые дают только заданный вид взаимодействия, авторы предлагают строить помещения таким образом, чтобы их жители и структура могли (и должны) взаимно влиять друг на друга.
Такой подход дает возможность двигаться дальше и нам. Вместо того, чтобы собирать в единое лоскутное одеяло отдельные дизайнерские решения, ориентированные на всё увеличивающееся число веб-устройств, мы можем рассматривать их как различные грани одного и того же варианта взаимодействия.
Мы можем разрабатывать дизайн, стремясь к оптимальному качеству представления, при этом встраивая в него технологии, которые предлагают не только более гибкую, но и более адаптивную к различным устройствам отображения реализацию.
Проще говоря, нам необходимо начать применять на практике адаптивный веб-дизайн. Но как это сделать?
Знакомьтесь, это — Media Query
Еще со времен CSS 2.1 наши таблицы стилей имеют некоторое представление об устройствах отображения благодаря media types. Если вы когда-либо писали таблицу стилей для печати, то основная суть вам уже известна:
<link rel="stylesheet" type="text/css" href="core.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />
В надежде, что мы будем создавать дизайн страниц для вывода не только на экран или принтер, CSS-спецификация предоставила нам список допустимых media types, каждый их которых соответствует определенному классу устройств.
Но, к сожалению, большинство браузеров и устройств не воссоединились с духом спецификации.Часть из приведенных типов была реализована не полностью, а другая часть и вовсе оставлена без внимания.
Следует поблагодарить W3C за то, что он включил media queries в состав спецификации CSS3, тем самым улучшив перспективность media types. Media queries позволяют нам ориентироваться не только на определенный класс устройств, но и в режиме реального времени проверять их физические характеристики.
Например, после недавнего роста и улучшения мобильного WebKit, media queries стали популярной клиентской техникой отдачи специализированных таблиц стилей для iPhone, Android-телефонов и ему подобных. Чтобы добиться этого, мы можем добавить media query в атрибут media
для соответствующей таблицы стилей:
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />
Media query состоит из двух частей:
- media type (
screen
)
- и, собственно, сам запрос в скобках, содержащий конкретную media feature (
max-device-width
) и ее точное значение (480px
) для проверки.
Мы как бы спрашиваем устройство о том, меньше или равно его разрешение по горизонтали (max-device-width
), чем значение в 480 пикселей.
Если тест пройден успешно (т.е., мы просматриваем верстку на устройстве с маленьким экраном, как, например, у iPhone), то устройство подгрузит себе файл shetland.css. В противном случае ссылка на эти таблицы стилей будет проигнорирована.
Дизайнеры и раньше экспериментировали с макетами, поведение которых зависело от разрешения экрана. В основном эти опыты опирались на такие JavaScript-решения, как великолепный скрипт Кэмерона Адамса (CAMERON ADAMS).
Но спецификация media queries обеспечивает поддержку целого ряда media features, которые выходят далеко за рамки простого разрешения экрана и значительно расширяют спектр того, что мы можем подвергнуть тестированию.
Вы можете одновременно тестировать в одном запросе значения нескольких свойств, объединяя их при помощи ключевого слова and
:
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />
Кроме того, мы не ограничены в добавлении media queries только в тег link
. Мы можем добавить их непосредственно в CSS-код, как часть правила @media
:
@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}
Или как часть директивы @import
:
@import url("shetland.css") screen and (max-device-width: 480px);
В любом случае эффект один и тот же. Если устройство проходит тест, заданный нашим media query, то соответствующий CSS-код применяется к верстке.
Проще говоря, media queries — это своего рода условные комментарии. Вместо того, чтобы ориентироваться на конкретную версию конкретного браузера, мы можем в режиме реального времени вносить изменения в верстку макета, если она при масштабировании выходит за пределы базового/идеального разрешения.
Адаптация, реакция и преодоление
Теперь направим наше внимание на изображения, которые находятся внизу нашей страницы. В текущей версии CSS-код, который к ним относится, выглядит примерно так:
.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}
Я специально опустил ряд типографических свойств, чтобы сфокусироваться на блочной модели. Каждый элемент с классом .figure
занимает примерно треть от ширины родительского контейнера. К тому же последнее изображение в каждом ряду имеет нулевой правый внешний отступ (li#f-mycroft, li#f-winter
).
И этот код работает довольно хорошо вплоть до того момента, пока область просмотра не становится заметно меньше или, наоборот, шире, чем мы изначально проектировали. При помощи media queries мы можем внести небольшие правки, которые учитывают текущее разрешение экрана, и, таким образом, адаптируют дизайн для наилучшей реакции на изменение параметров отображения.
Для начала сделаем поток контента на нашей странице линейным, когда область просмотра по ширине становится меньше заданного порогового значения, скажем, в 600 пикселей. Для этого в конце нашей таблицы стилей добавим следующий блок @media
:
@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}
Если вы посмотрите на новый вариант страницы с нашим примером в современном браузере, при этом сделав ширину окна менее 600 пикселей, то media query отключит свойство текучести у основных структурных блоков и поставит их в одну линию друг над другом.
Таким образом наш миниатюрный дизайн получил привлекательные формы, однако, изображения все еще уменьшаются не разумно. Если мы добавим другой media query, то сможем изменить принцип их отображения:
@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}
Наши изображения смогли адаптироваться
для более лучшего отображения на небольших экранах.
Не обращайте внимания на чудовищную форму записи процентов. Просто значение ширины для резиновой верстки мы пересчитали в соответствующее значение для нового линейного принципа расположения блоков.
Проще говоря, мы переходим от трех-колоночной версии макета к двух-колоночной, когда область просмотра становится менее 400 пикселей по ширине. При этом разборчивость изображений улучшается.
На самом деле мы можем точно так же поступить и с широкоформатными экранами. Для больших разрешений мы можем создать из наших изображений шесть колонок, расположив их все в один ряд:
@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}
Теперь наши изображения работают прекрасно во всем спектре разрешений, оптимизируя свои размеры и взаимное расположение в зависимости от ширины окна браузера или разрешения экрана.
Указав большее значение для min-width
в новом media query,
мы можем расположить наши изображения в один ряд.
И это только начало.
Используя media queries в нашем CSS-коде, мы можем изменить не только расположение нескольких изображений. Мы можем внедрять новые/альтернативные варианты дизайна, тонко настроенные под различные диапазоны разрешений. Мы можем делать навигацию более заметной на широких экранах, или перемещать ее в позицию над логотипом для устройств с небольшим экраном.
Проектируя адаптивно, мы можем не только расположить
контент линейно и последовательно,
но и оптимизировать его отображение для целого ряда экранов.
Но адаптивный дизайн не ограничивается изменениями в раскладке страницы. Media queries позволяют нам заниматься невероятно тонкой настройкой этих изменений. Мы можем:
- увеличивать для сенсорных устройств с маленькими экранами область клика ссылки согласно закону Фитса;
- выборочно показывать или скрывать элементы, которые могут улучшать навигацию;
- и даже использовать адаптивную типографику для плавного изменения размера шрифта и переформатирования текста, улучшая его читаемость на соответствующих устройствах.
Технические моменты
Следует отметить, что media queries имеют хорошую поддержку во всех современных браузерах.
Браузеры Safari 3+, Chrome, Firefox 3.5+ и Opera 7+, а также Opera Mobile и мобильный WebKit, имеют встроенные парсеры media queries (в старых версиях этих браузеров такой поддержки нет). И хотя Microsoft взяла на себя обязательства по поддержке media queries в 9 версии Internet Explorer, на данный момент их реализацией этот браузер похвастаться не может*.
*На момент написания статьи Internet Explorer 9 еще не вышел в релиз. В 9-ойверсии браузера от Майкрософт обещанная поддержка была полностью реализована. — Прим. переводчика.
Однако, если вас интересует реализация поддержки возможностей media queries в старых браузерах, то вот вам JavaScript-овые лучики надежды:
- jQuery-плагин 2007 года выпуска предлагает несколько ограниченную реализацию media queries, в которой используются только свойства
min-width
и max-width
, добавляемые в тег link
.
- Недавно разработанная библиотека css3-mediaqueries.js, которая обещает «научить IE 5+, Firefox 1+ и Safari 2 парсить, тестировать и применять CSS3 Media Queries» путем подключения их через блоки
@media
. Несмотря на то, что версия библиотеки еще только «1.0», мне она показалась довольно стабильной, и я планирую следить за ее дальнейшей разработкой.
У разработчиков бывают вполне объяснимые ситуации, когда использовать JavaScript-решение не приемлемо. Именно такие случаи дают дополнительный вес решению делать верстку резиновой. Она обеспечит ваш дизайн определенным запасом гибкости в браузерах и устройствах, которые не поддерживают media queries.
Только вперед
Резиновая верстка, масштабируемые изображения и media queries — вот три технических составляющих адаптивного дизайна. Но для их использования необходимо думать по-другому.
Вместо того, чтобы изолировать наш контент в обособленные и зависимые от устройств представления, мы можем использовать media queries для постепенного улучшения наших проектов в самых различных контекстах.
Это не означает, что создание отдельных сайтов для отдельных устройств не имеет смысла с точки зрения бизнеса. Например, если перечень целей, которых желает достичь посетитель мобильной версии вашего сайта, более ограничен по сравнению с обычной версией, то соседское сосуществование обеих версий может быть вполне удачным решением.
Но такая модель дизайнерского мышления не должна быть моделью по-умолчанию. Сегодня мы проектируем продукты, которые, как никогда ранее, должны поддерживать всю палитру вариантов взаимодействия. И по большому счету, адаптивный веб-дизайн открывает нам дорогу вперед, позволяя «создавать изменчивую природу вещей».
Об авторе
Этан Мэркотт — веб-дизайнер и разработчик, которого глубоко волнуют красивый дизайн, элегантный код, а также их взаимное пересечение. На протяжении нескольких лет Этан имел удовольствие работать с такими заказчиками, как the Sundance Film Festival, Stanford University, New York Magazine and The Today Show.
Он обильно общается в твиттере и хочет стать неудержимым ниндзя-роботом, когда вырастет.
Его последняя книга называется «Адаптивный веб-дизайн».
53.740749
87.113487