Чувствуете себя королем мира? Тогда мне именно сейчас следует сказать, что не все браузеры, распознающие @media, поддерживают создание запросов для всех характеристик, указанных в спецификации.
Табл. 4.1. Характеристики устройств, тестируемых с использованием медиазапросов
Вот вам пример. Когда Apple выпустила свой первый iPad, он поддерживал медиазапрос orientation. Это значит, что вы могли написать запрос orientation: landscape или orientation: portrait для обслуживания устройства средствами CSS. Круто, да? К сожалению, iPhone не поддерживал запрос orientation до тех пор, пока несколько месяцев спустя не вышло обновление операционной системы. В то время как все устройства позволяли пользователю изменить ориентацию, браузер iPhone не понимал запросы на эту характеристику.
Мораль этой истории? Внимательно изучайте устройства и браузеры на предмет запросов характеристик, которые они поддерживают, и проверяйте их надлежащим образом.
В то время как поддержка современных браузеров и устройств все еще находится в процессе развития, медиазапросы дают нам прекрасную возможность четко сформулировать то, как именно должен выглядеть наш дизайн на различных устройствах и браузерах.
Более отзывчивый робот
Медиазапросы – это последний элемент отзывчивого веб-сайта. На протяжении двух глав мы делали гибкий макет, который, однако, является всего лишь основой. Теперь мы можем использовать медиазапросы для коррекции любых визуальных дефектов, возникающих при изменении формы и размеров области просмотра.
Кроме того, мы можем использовать медиазапросы для оптимизации отображения нашего контента в соответствии с требованиями определенного устройства, создавая альтернативные макеты под определенные диапазоны разрешений. Загружая правила стилей, касающиеся этих диапазонов, медиазапросы позволяют нам создавать страницы, более чувствительные к требованиям устройств, которые их отображают.
Другими словами, объединяя гибкие макеты и медиазапросы, мы наконец-то сможем сделать наш сайт отзывчивым.
Приступим.
В компании с viewport
Мы уже определили основные пункты, на которые стоит обратить внимание в нашем дизайне. Но прежде чем применять медиазапросы, мы должны еще раз взглянуть на оригинальный макет.
Когда в 2007 году Apple выпустила iPhone, она создала новое атрибутивное значение для элемента meta Mobile Safari: viewport (http://bkaprt.com/rwd/29/). Зачем? Размеры дисплея iPhone – 320 х 480, но Mobile Safari фактически отображает веб-страницы шириной 980 пикселей. Если вы когда-нибудь заходили на сайт газеты New York Times (http://nytimes.com) с телефона с функцией WebKit (рис. 4.9), вы могли видеть это в действии: Mobile Safari рисует страницу на холсте шириной 980px, а затем сжимает ее, чтобы уместить на экране с разрешением 320 х 480.
Рис. 4.9. По умолчанию браузер Mobile Safari воспроизводит контент с шириной 980px, даже когда вы держите телефон в горизонтальной плоскости и ширина ограничена 320px
При помощи тега viewport мы можем контролировать размеры этого холста и задавать точные размеры области просмотра браузера. Например, мы можем установить фиксированную ширину в 320px:
<meta name="viewport" content="width=320" />
С того момента, как Apple представила механику viewport, многие разработчики браузеров приняли ее, сделав стандартом де-факто. Давайте попробуем включить его в наш дизайн, который скоро станет отзывчивым. Однако вместо того, чтобы устанавливать фиксированную ширину в пикселях, используем подход, не зависящий от разрешения. В блоке head нашего HTML пишем элемент meta:
<meta name="viewport" content="initial-scale=1.0, width=device-width" />
Свойство initial-scale устанавливает уровень масштабирования страницы на 1.0, или 100 %, что обеспечивает некоторую согласованность распознающих viewport браузеров, для устройств с маленькими экранами. (Более детальную информацию по масштабированию под различные мониторы вы сможете найти в объяснении Mozilla: http://bkaprt.com/rwd/30/.)
Большое значение для нас имеет параметр width=device-width, который делает ширину окна просмотра браузера равной ширине экрана устройства. Например, на iPhone область макета Mobile Safari уже составляет не 980px, а 320 пикселей в портретном режиме и 480 – в ландшафтном.
Имея на руках это значение, мы можем использовать max-width и min-width для поиска диапазонов разрешений ниже или выше определенного порога и загружать в CSS, предназначенного для этих диапазонов. Кроме того, в этом случае браузеры, распознающие запросы, могут воспользоваться ими, что сделает наш дизайн отзывчивым для всех пользователей, неважно, с какого устройства они его просматривают – с телефона, планшета, стационарного компьютера или ноутбука.
Так, что-то я заболтался. Давайте лучше взглянем на пресловутые запросы в действии.
Медиазапросы в действии
Вы помните тот большой внушительный заголовок (рис. 4.10)? Вот CSS, который его сделал таким:
.main-title {
background: #000;
color: #FFF;
font: normal 3.625em/0.9 "League Gothic", "Arial Narrow", Arial, sans-serif; /* 58px / 16px */
text-transform: uppercase;
}
Рис. 4.10. При должном умении заголовок может стать вполне внушительным
Я упустил несколько презентационных свойств, потому что меня больше заботит то, как этот ужасный огромный заголовок выглядит при небольшом разрешении. Он написан торжественным шрифтом League Gothic (http://bkaprt.com/rwd/31/) белого цвета (color: #FFF) на черном фоне (background: #000). И если вдруг кто-то все еще не воспринимает его всерьез, учтите, что он написан заглавными буквами (с помощью text-transform) размером 3,625 em, или 58px.
Что ж, пока все идет хорошо. Но, как мы уже убедились, если уменьшить окно браузера или просматривать страницу на устройстве с меньшим экраном, его дизайн выглядит неправильно, поскольку совсем не масштабируется.
Давайте исправим этот недостаток.
Сначала вставим блок @media где-то после первого правила .main-title, в котором напишем запрос более узкого диапазона расширения:
@media screen and (max-width: 768px) { … }
В этом запросе мы дали команду браузеру отображать вложенный CSS только в том случае, если ширина окна просмотра не превышает 768 пикселей. Почему 768? Потому что ширина окна просмотра телефонов, поддерживающих медиазапросы, как и большей части современных планшетов, меньше этого значения. По крайней мере, в определенных режимах. Например, разрешение iPad в портретном режиме составляет 768 px, а в ландшафтном – 1024 px.
Но поскольку мы используем max-width, а не max-device-width, более узкие окна браузеров на вашем компьютере или ноутбуке также примут этот диапазон разрешения. (Помните: характеристики width и height определяют область просмотра или окно браузера, тогда как параметры device-width и device-height – размеры всего экрана).
Написав этот запрос, можем приступать к обработке тех элементов дизайна, которые не масштабируются. Сначала давайте еще раз обратимся к нашему огромному заголовку. Чтобы сделать его более удобоваримым, впишем в медиазапрос правило .main-title с другими свойствами CSS – вместо тех, которые вызывают у нас только головную боль:
@media screen and (max-width: 768px) {
.main-title {
font: normal 1.5em Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, Helvetica, sans-serif; /* 24px / 16px */
}
}
Первое правило .main-title применяется всеми браузерами, которые читают наш CSS. Однако для более узких окон браузеров или устройств (разрешение которых не шире 768 пикселей) применяется второе правило, заменяющее первое. Мы сделали два изменения: во-первых, уменьшили кегль элемента .main-title с 3,625em (около 58 пикселей) до 1,5em, или 24px. На мелких экранах такой шрифт смотрится лучше.
Во-вторых, шрифт, который мы прежде использовали для этого заголовка – наш любимый League Gothic, совсем не смотрится на таких экранах (рис. 4.11). Поэтому я решил заменить его семейством шрифтов (Calibri, Candara, Segoe, Segoe UI, Optima, Arial, Helvetica, sans-serif). Теперь заголовок стал более читабельным (рис. 4.12).
Рис. 4.11. Шрифт League Gothic, несмотря на всю свою прелесть, кажется слишком мелким и узким
Рис. 4.12. Не так красиво, как League Gothic? С ним вообще сложно что-то сравнить. Однако этот новый шрифт читается куда лучше, да и вполне соответствует дизайну
Вы, наверное, заметили, что мы не переписывали другие свойства в первом правиле .main-title. То есть черный фон, белый цвет шрифта и заглавные буквы все еще применяются к нашему уменьшенному заголовку. Запрос переписал только те характеристики, которые нас не устраивали.
Вуаля! При помощи медиазапроса мы исправили заголовок, и теперь на маленьких экранах он смотрится прекрасно (рис. 4.13).
Но это только начало. Мы можем не только подправить шрифтовое оформление, но и решить более сложные проблемы, связанные с дизайном.
Рис. 4.13. Сравните изначальный вариант заголовка (вверху) с вариантом, получившимся вследствие применения запроса
Все дело в деталях
Давайте сделаем новый медиазапрос и немного подправим макет нашей страницы. Помните наш гибкий контейнер #page из второй главы? Вот как выглядит его CSS на данный момент:
#page {
margin: 36px auto;
width: 90 %;
}
Мы видим, что контейнер занимает 90 % окна браузера и отцентрирован по горизонтали (margin: 36px auto). Прекрасно, но давайте добавим правило в уже существующий медиазапрос, чтобы подрегулировать его характеристики при отображении на устройстве с разрешением меньше оригинального:
@media screen and (max-width: 768px) {
#page {
position: relative;
margin: 20px;
width: auto;
}
}
Теперь в случае, если разрешение будет меньше 768 пикселей, элемент #page займет всю ширину окна браузера минус поля по краям шириной 20px. Это небольшое изменение обеспечивает нам больше пространства на экранах с меньшим разрешением.
С контейнером разобрались, теперь обратимся к области контента:
@media screen and (max-width: 768px) {
#page {
margin: 20px;
width: auto;
.welcome,
.blog,
.gallery {
margin: 0 0 30px;
width: auto;
}
}
Новое правило выбирает три блока контента верхнего уровня – введение (.welcome), блог (.blog) и фотогалерею (.gallery) – и убирает их горизонтальные отступы, позволяя им занять всю ширину #page.
Таким образом, мы привели макет нашей страницы к более линейному виду, сделав его более читабельным на устройствах с маленькими экранами (рис. 4.14). Я заслужил похвалу?
Нет? Что вы сказали? В верхней части страницы все еще висит пугающе огромная картинка (рис. 4.15)?
Рис. 4.14. Наш контент кажется более выровненным благодаря применению двух дополнительных правил. Однако чего-то еще не хватает…
Рис. 4.15. Однозначно над этим рисунком еще надо поработать
Ну что ж, наверное, и эту проблему можно решить, если она вас действительно беспокоит. Но прежде давайте снова взглянем на первоначальную разметку этого изображения, которое должно быть частью модуля слайд-шоу (и это еще предстоит сделать):
<div class="welcome section">
<div class="slides">
<div class="figure">
<b><img src="img/slide-robot.jpg" alt="" /></b>
<div class="figcaption">…</div>
</div><!– /end.figure – >
<ul class="slide-nav">
<li><a class="prev" href="#">Previous</a></li>
<li><a class="next" href="#">Next</a></li>
</ul>
</div><!– /end.slides – >
<div class="main">
<h1 class="main-title">You can never be too sure.</h1>
</div><!– /end.main – >
</div><!– /end.welcome.section – >
Изрядный кусок HTML, да? Но по существу мы сделали модуль .welcome, в который поместили изображение и идущий за ним вступительный текст (.main). Изображение, в свою очередь, входит в блок .figure, а сам img заключен в элемент b, который действует как хук для CSS.
Звучит слишком заумно? И я знаю почему. Но элемент b, как бы глупо здесь ни выглядел, на самом деле обрабатывает большой кусок макета. Вот как выглядит соответствующий CSS:
.slides.figure b {
display: block;
overflow: hidden;
margin-bottom: 0;
width: 112.272727 %; /* 741px / 660px */
}
.slides.figure b img {
display: block;
max-width: inherit;
}
Сначала мы задали свойству hidden в элементе b значение overflow, то есть контейнер обрезал любой лишний контент. Теперь же гибкие изображения меняют свои размеры при изменении элемента b. Поэтому мы отменяем масштабирование max-width: 100 % по отношению к изображениям слайд-шоу (max-width: inherit). В результате картинка робота будет попросту обрезана, если ее ширина превысит содержащий ее элемент b.
Как видите, ширина элемента b на самом деле больше 100 %. Мы использовали формулу target ÷ context = result, чтобы создать элемент больше, чем модуль .welcome, благодаря чему изображение немного выходит за рамки с правой стороны.
Как назло, ни один из этих эффектов не будет работать при низком разрешении. Но я везучий парень. Так что давайте кое-что допишем в конце нашего медиазапроса:
@media screen and (max-width: 768px) {
.slides.figure b {
width: auto;
}
.slides.figure b img {
max-width: 100 %;
}
}
Первое правило задает элементу b ширину auto, делая ее такой же, как и ширина его контейнера. Второе правило восстанавливает max-width: 100 %, которое мы обсуждали в третьей главе, позволяя изображению увеличиваться и уменьшаться вместе с контейнером. Вместе эти два правила не позволяют изображению выходить за рамки контейнера, а при расширении – за рамки остальной части дизайна (рис. 4.16). Не знаю, как вы, а я выдохнул с облегчением.
Рис. 4.16. Наш рисунок теперь оказался на своем месте. Я испытываю облегчение. А вы?
Рис. 4.17. Поле Contact Us, почему ты нас так ненавидишь?
И все же, прежде чем мы сможем расслабиться, нам нужно исправить еще кое-что. Навигация в верхней части страницы все еще выглядит сильно сжатой. Кроме того, если хоть немного изменить область просмотра, текст снова переносится на следующую строчку (рис. 4.17).
Разметка шапки довольно простая:
<h1 class="logo">
<a href="/">
<i><img src="logo.png" alt="Robot or Not?" /></i>
</a>
</h1>
<ul class="nav nav-primary">
<li id="nav-blog"><a href="#">The ’Bot Blog</a></li>
<li id="nav-rated"><a href="#">Top Rated</a></li>
<li id="nav-droids"><a href="#">Droids of the Day</a></li>
<li id="nav-contact"><a href="#">Contact Us</a></li>
</ul><!– /end ul.nav.nav-primary – >
Итак, мы обозначили логотип тегом h1, сделали маркированный список для навигации и присвоили им классы .logo и .nav-primary соответственно. Но что делать с CSS?
.logo {
background: #C52618 url("logo-bg.jpg");
float: left;
width: 16.875 %; /* 162px / 960px */
}
.nav-primary {
background: #5E140D url("nav-bg.jpg"); padding: 1.2em 1em 1em;
}
.nav-primary li {
display: inline;
}
Стили достаточно простые. Мы применили фоновые изображения к обоим элементам, а не к самому макету: мы подвинули изображение влево, чтобы оно перекрывало навигацию. А элементам списка внутри .nav-primary соответствует свойство display: inline. Это решает нашу проблему, по крайней мере, пока страница не становится настолько узкой, что внутренние элементы переносятся на следующую строчку.
Вот как выглядит медиазапрос:
@media screen and (max-width: 768px) {
.logo {
float: none;
margin: 0 auto 20px;
position: relative;
}
.nav-primary {
margin-bottom: 20px;
text-align: center;
}
}
Мы убрали свободное перемещение, которое было первоначально задано .logo, и отцентрировали его по горизонтали над меню. Также мы установили text-align: center для .nav-primary, расположив все элементы по центру. Все изменения видны невооруженным глазом (рис. 4.18). Логотип и основная навигация находятся в своих собственных рядах со своими собственными свойствами.
Рис. 4.18. Мы можем полностью перестроить верхнюю часть заголовка, чтобы дать возможность и логотипу, и строке навигации дышать полной грудью
Лично мне нравится, как выглядит навигация, однако расслабляться все равно еще рано. Для элементов навигации осталось не так уж и много места. Фактически, если мы хоть немного изменим размер экрана, наша четкая линия снова сломается, и текст перенесется на следующую строку (рис. 4.19).
(У меня какая-то личная неприязнь к такому тексту. Не знаю почему.)
Рис. 4.19. Слушайте, это уже не смешно
Мы обнаружили еще один проблемный момент, который невозможно исправить, просто передвинув логотип в свой собственный ряд. Значит, давайте напишем еще один медиазапрос и уберем возможность появления такой проблемы:
@media screen and (max-width: 768px) {