Но при этом оба подхода абсолютно нечувствительны к содержанию. Каждый из них устанавливает некоторые основные правила, которым следуют изображения по отношению к своим контейнерам: max-width: 100 % масштабирует картинку в соответствии с размерами контейнера, а overflow позволяет убрать лишние данные, выходящие за его пределы.
Но что если вам предстоит работа со сложной графикой или изображением, которое несет определенную информационную нагрузку (рис. 3.16)? В этом случае простое масштабирование или обрезание нежелательны, поскольку могут помешать пользователю правильно понять информацию, содержащуюся в изображении.
Рис. 3.16. Эта отличная инфографика с сайта BBC News содержит жизненно необходимую с точки зрения контента информацию. Простое масштабирование может оказаться неэффективным
В этом случае нужно найти способы передачи различных вариантов одной и той же картинки в разных диапазонах разрешений. Другими словами, вы можете создать один образец для десктопных браузеров, а второй, более линейный, – для устройств с маленькими экранами. Задав эти параметры, вы можете положиться на сервер, который сам выберет наиболее подходящее изображение.
Такое решение выходит за рамки данной книги (и не всегда по силам вашему покорному слуге), однако дизайнер-разработчик Брайан Ригер описал возможный подход в своем блоге (http://bkaprt.com/rwd/23/), откуда вы и сможете его скачать.
Если вы решили использовать серверное решение, его можно укрепить различными клиентскими приемами, которые мы уже обсуждали. Например, вы можете создать несколько вариантов изображения под разные диапазоны разрешений, а затем использовать правило max-width: 100 %, чтобы сгладить переход на другие устройства, браузеры и диапазоны разрешений.
Гибкие сетки и изображения как древо познания
Итак, к этому моменту мы изучили все, что необходимо для успешного создания сложных, но гибких макетов: простая математика для гибких сеток и немного стратегических решений для изображений и других медиафайлов. Все эти знания вы можете применять не только по отношению к блогу, который мы писали, но и ко всему сайту Robot or Not, создавая дизайн, основанный на системе пропорций и процентов, без всяких пикселей (рис. 3.17).
Имея на руках гибкую основу, мы готовы добавить еще один ингредиент к нашему отзывчивому дизайну.
Рис. 3.17. Использовав рекомендации, содержащиеся в двух главах, мы получили завершенный и гибкий макет, который может расширяться и сужаться в зависимости от размеров окна браузера
4. Медиазапросы
В общем-то, я всегда был противником фиксированной верстки. Я с самого начала чувствовал, что будущее – за макетами, которые обладают гибкостью хоть в малейшей степени, ведь они всегда могут подстроиться под размеры окна, экрана или разрешения устройства. Более того, настаивая на необходимости гибкости, я часто использовал эпитеты «перспективный» и «приспосабливающийся». Увы, ко мне не очень-то прислушивались и считали страшным занудой.
Но в какой-то момент все изменилось.
Однако вернемся к нашему сайту Robot or Not. Мы сделали его максимально гибким, однако он все же еще не очень надежный. Да, «резиновая» сетка сделала его менее чувствительным к изменениям размера окна или разрешения экрана, чем при фиксированном макете. Однако изменения в размере и форме окна браузера могут вызвать деформацию всей верстки.
И знаете что? В этом нет ничего страшного!
Приступим к лечению
Понимаю, это неприятно, но все же нам придется понять, что именно случилось с нашим дизайном и где он нарушился. Определив все проблемы, мы сможем эффективно их устранить, даже если придется немного помучиться в процессе.
Поскольку мы работаем с гибким макетом, мы можем просто изменить размеры окна браузера. Это, конечно, не заменит полноценного тестирования на отдельных устройствах, но позволит быстро оценить, как себя поведет наш дизайн в различных диапазонах разрешений. Мы увидим, как именно он будет выглядеть на экране телефона, планшета или другого устройства.
Расстановка акцентов
Прежде всего, изменим разрешение окна браузера с 1024 пикселей на 760 пикселей (рис. 4.1). Проблемы сразу же станут весьма наглядными.
Рис. 4.1. Чтобы понять, каким образом будет выглядеть наш дизайн при разном разрешении экрана, достаточно изменить размеры окна браузера
В первоначальном дизайне было несколько привлекательных элементов: впечатляющие заголовки, яркая выделяющаяся картинка и широкие поля. Все это осталось, но – с визуальной точки зрения – стало каким-то невзрачным.
Обратите внимание на то, что картинка в верхней части сайта стала занимать практически всю страницу (рис. 4.2). Поскольку мы обрезали ее при помощи свойства overflow, она не адаптировалась под изменения всей сетки. Кроме того, само изображение – наш любимый робот – теперь обрезано. То есть картинка не только огромная, но и непонятная. Кошмар какой-то…
Рис. 4.2. В верхней части нашего дизайна творится что-то не то
На фоне этой гигантской картинки логотип выглядит совсем крошечным, а поле между навигацией и картинкой исчезло. Глядя на все это, испытываешь приступ клаустрофобии.
Мне неприятно это говорить, но даже при небольшом уменьшении разрешения сайт превращается в нелепое нагромождение различных элементов.
Маленькая сетка, большие проблемы
И это еще не самое ужасное. Если мы уменьшим окно браузера до 600 пикселей – ширины окна маленького браузера или портретного режима на планшетном компьютере, – наша головная боль только усилится (рис. 4.3). В верхней части экрана творится полное безобразие: картинка обрезана настолько, что непонятно, что там вообще изображено, а бедный логотип стал еще меньше. Навигация же выглядит просто непотребно. С этим нужно срочно что-то делать.
Рис. 4.3. Любой посетитель сайта будет в восторге от нашего исковерканного дизайна (это сарказм)
Двигаемся ниже. Господи, что же это происходит с сайтом (рис. 4.4)! Раньше двухколоночная верстка обеспечивала легкий доступ к дополнительной информации, сейчас же она сжимает текст, такие короткие строчки читать крайне неудобно. Фотография не совпадает с текстом, а что на ней изображено, не понять никому.
Рис. 4.4. Эта запись напоминает японское стихотворение хайку – строчки, короткие до боли
И наконец, заканчивая наш печальный обзор, посмотрим на фотографии в нижней части страницы. Они выглядят хуже всего (рис. 4.5), даже хуже картинки в верхней части. Они такие маленькие, что разглядеть, что там на них, невозможно.
Широкие поля, которые мы использовали для обрамления этих картинок, превратились в огромные пробельные моря, поглотившие их.
Рис. 4.5. Мелкие картинки, монструозные поля. Отвратительно!
Широкоэкранные неприятности
Однако проблемы возникают не только тогда, когда разрешение экрана меньше. Если мы максимально увеличим окно браузера, на свет вылезут новые проблемы. Верхняя часть страницы выглядит довольно неплохо (рис. 4.6), правда, картинка теперь меньше, чем выделенное под нее место. В остальном же все более-менее нормально… Ну, далеко от идеального, но вытерпеть можно. Сетка в целом сохранилась хорошо.
Рис. 4.6. Верхняя часть выглядит довольно широкой
А теперь прокрутим страницу вниз, и наше радостное настроение вмиг испарится (рис. 4.7). Помните, какими короткими выглядели строчки текста в маленьком окне? Глядя на то, что появилось на экране, я начинаю по ним скучать. Теперь строчки стали невероятно длинными, и, несмотря на то, что ничто не доставляет мне большего удовольствия, чем выискивать следующую строчку после прочтения предыдущей, придется искать другой способ.
Рис. 4.7. Двигаясь вниз по странице, мы видим все больше проблем. Длинные строки, крошечные изображения, печальный Итан
Ко всему прочему, фотографии в нижней части страницы стали невероятно большими (рис. 4.8). Выглядят они неплохо, но занимают слишком много места. На самом деле на моем мониторе даже и не видно, есть ли что-то над или под этим блоком. Интересно, можем мы сделать хоть что-то, чтобы читатели не сломали глаза, рассматривая наш сайт?
Рис. 4.8. Говоря техническим языком, эти изображения слишком крупные и массивные
Насущные проблемы
Итак, мы определили основные визуальные неполадки. Однако нужно смотреть на проблему шире. Как только мы меняем оригинальное разрешение, сетка оказывает нежелательное воздействие на контент. Ее пропорции ограничивают содержание при низких разрешениях и окружают его пустым пространством – при высоких.
Причем эта проблема возникает не только с гибкими макетами. Ни один дизайн, фиксированный или гибкий, не сможет масштабироваться вне контекста, для которого он спроектирован.
Так как же нам сделать дизайн, который будет адаптироваться к изменениям разрешения экрана и размеров области просмотра? Как сделать так, чтобы страница оптимизировалась в соответствии с браузером и устройством, на котором ее просматривают?
Другими словами, как сделать наш дизайн более отзывчивым?
Навстречу отзывчивости
К счастью, Консорциум Всемирной паутины (World Wide Web Consortium, W3C) уже некоторое время занимается этой проблемой. Но чтобы лучше понять решение, которое в результате было представлено, обратимся к предыстории.
Знакомьтесь: медиатипы
Первым шагом в решении проблемы стали медиатипы (media types), часть спецификации CSS2 (http://bkaprt.com/rwd/24/). Вот как они первоначально описывались:
Иногда таблицы стилей для различных медиатипов могут иметь одинаковое свойство, но требовать разных значений для этого свойства. Например, свойство font-size можно использовать как для монитора, так и для вывода документа на печать. Эти два медиатипа отличаются друг от друга и требуют разных значений для одного и того же свойства; документ обычно имеет больший шрифт на мониторе, чем на бумаге. Поэтому это нужно отобразить в таблице стилей или в разделе таблицы, применяемой к определенным медиатипам.
Ничего не понятно, да? Давайте попробуем разобраться без нагромождения терминов.
Вы писали когда-нибудь стили для печати (http://bkaprt.com/rwd/25/)? Тогда вы, наверное, знакомы с понятием разработки для различных видов медиа. Даже идеальное браузерное отображение не делает никакой разницы между десктопными браузерами и принтерами или между мобильными устройствами и голосовым браузером. Чтобы решить эту проблему, W3C создала список медиатипов (http://bkaprt.com/rwd/26/) для классификации каждого браузера или устройства по медиакатегориям. Медиатипы могут принимать значения: all, braille, embossed, handheld, print, projection, screen, speech, tty и tv.
С некоторыми из этих медиатипов, как, например, print, screen или даже projection, вы уже работали. Некоторые другие – embossed (для брайлевских принтеров) или speech (для голосовых браузеров и интерфейсов) – встречаются впервые. Но все эти медиатипы созданы с одной целью: чтобы мы могли лучше проектировать дизайн для каждого типа браузера или устройства, просто загружая нужный CSS. Следовательно, устройство с экраном будет игнорировать CSS, созданный для медиатипа print, и наоборот. А для стилевых правил, которые применимы ко всем устройствам, в спецификации создана супергруппа all. На практике это означает правку media-атрибута ссылки:
<link rel="stylesheet" href="global.css" media="all" />
<link rel="stylesheet" href="main.css" media="screen" />
<link rel="stylesheet" href="paper.css" media="print" />
А также создание блока @media в таблице стилей и его привязку к определенному медиатипу:
@media screen {
body {
font-size: 100 %;
}
}
@media print {
body {
font-size: 15 pt;
}
}
В любом случае спецификация предлагает браузеру определить, к какому медиатипу он относится. («Я десктопный браузер! Я отношусь к медиатипу screen», «Я пахну чернилами и тонером: я тип print», «Я браузер видеоконсоли: я тип tv» и т. д.) Загрузив страницу, браузер будет отображать только тот CSS, который относится к определенному медиатипу, и игнорировать все остальные. И – в теории – это потрясающая идея.
Но теория – это, наверное, последнее, что нужно занятому по горло веб-дизайнеру.
Неправильное распределение типов
Когда на сцене появились все эти браузеры для устройств с маленькими экранами, как, например, телефоны или планшеты, с ними пришли и проблемы. В соответствии со спецификацией решить эти проблемы несложно, нужно просто создать таблицу стилей для медиатипа handheld:
<link rel="stylesheet" href="main.css" media="screen" />
<link rel="stylesheet" href="paper.css" media="print" />
<link rel="stylesheet" href="tiny.css" media="handheld"/>
Проблемы скорее кроются в нас самих, по крайней мере, частично. На первых мобильных устройствах не было эффективно работающих браузеров, поэтому мы просто игнорировали их, разрабатывая вместо этого таблицы стилей для медиатипов screen или print. А когда такие браузеры появились, в Сети не было достаточно CSS-файлов типа handheld. В результате многие разработчики мобильных браузеров решили использовать таблицы стилей для медиатипа screen.
А растущий диапазон мобильных устройств еще больше усложняет дело. Сможет ли одна и та же таблица стилей решить все проблемы для iPhone и для телефона пятилетней давности?
Знакомство с медиазапросами
К счастью, организация W3C включила в спецификацию CSS3 синтаксис медиазапросов, усовершенствовав методологию медиатипов. Медиазапросы позволяют не только ориентироваться на конкретный класс устройств, но и анализировать физические характеристики устройства, использующегося для отображения страницы (http://bkaprt.com/rwd/27/).
Взгляните на следующий отрывок:
@media screen and (min-width: 1024px) {
body {
font-size: 100 %;
}
}
Каждый медиазапрос, включая и этот, содержит два компонента:
1. Он начинается с медиатипа (screen), взятого из списка утвержденных медиатипов спецификации CSS2.1 (http://bkaprt.com/rwd/26/).
2. После типа идет сам запрос в скобках: (min-width: 1024px), который тоже можно разделить на две составляющие: название свойства (min-width) и соответствующее значение (1024px).
Считайте, что медиазапросы просто проверяют ваш браузер. В процессе считывания таблицы стилей браузер получает вопрос от медиазапроса screen and (min-width: 1024px): относится ли он к медиатипу screen, и если да, то имеет ли он ширину области просмотра не меньше 1024 пикселей. Если браузер отвечает на оба вопроса положительно, вложенные в запрос стили отображаются, в противном случае браузер попросту игнорирует их и занимается своими делами.
Этот медиазапрос вписан в объявление @media, что позволило включить его непосредственно в таблицу стилей. Но вы можете также поместить запрос в элемент ссылки (link), вставив его в атрибут media:
<link rel="stylesheet" href="wide.css" media="screen and (min-width: 1024px)" />
Кроме того, вы можете прикрепить его к инструкции @import:
@import url("wide.css") screen and (min-width: 1024px);
Лично я предпочитаю использовать @media, поскольку он хранит ваш код в отдельном файле, уменьшая количество внешних запросов браузера к серверу.
В принципе, неважно, куда вы впишете запрос, результат будет одинаковым: если браузер соответствует медиатипу и при этом выполняет условие, указанное в запросе, вложенные в запрос CSS выполняются, если нет – игнорируются.
Познакомьтесь с характеристиками
Однако дело не только в том, чтобы проверить ширину и высоту. Запросы могут проанализировать массу характеристик, указанных в спецификации. Но прежде чем мы приступим к этому делу, давайте сначала определимся с терминами, зачастую сложными и непонятными.
1. В спецификации сказано, что каждое устройство имеет «область просмотра» (display area) и «площадь изображения» (rendering surface). Ну и что это такое? Переведем на наш язык: окно просмотра браузера – это область просмотра, а весь монитор – площадь изображения. На вашем ноутбуке областью просмотра будет окно браузера; площадью изображения – экран.
2. Чтобы задать определенные значения, некоторые характеристики могут принимать префиксы min– и max-. Например, вы можете вписать (min-width: 1024px) и (max-width: 1024px), чтобы задать область просмотра более или менее 1024 пикселей соответственно.
Все понятно? Великолепно. С этим разобрались, давайте рассмотрим характеристики, которые в соответствии со спе-цификацией мы можем использовать в наших запросах (http://bkaprt.com/rwd/28/) (табл. 4.1).
А еще мы можем связывать несколько запросов в цепочку, соединяя их словом and:
@media screen and (min-device-width: 480px) and (orientation: landscape) { … }
То есть мы можем задать несколько характеристик в одном запросе, выполняя тем самым более сложный анализ устройства, на котором просматривается наш дизайн.
Знай свои характеристики
Чувствуете себя королем мира? Тогда мне именно сейчас следует сказать, что не все браузеры, распознающие @media, поддерживают создание запросов для всех характеристик, указанных в спецификации.
Табл. 4.1. Характеристики устройств, тестируемых с использованием медиазапросов