Рис. 4.20. Нужно ли говорить, насколько я доволен результатом? Нет? Тогда не буду
Стоит заметить, что нам не пришлось переписывать правила из предыдущего запроса (screen and (max-width: 768px)) в этот, поскольку, если экран соответствует требованию «у́же, чем 520 пикселей», то он автоматически соответствует и требованию «у́же, чем 768 пикселей». Другими словами, правила из обоих запросов применяются к самым мелким разрешениям. В результате проблемы могут возникнуть только с областями просмотра шириной менее 520 px.
Вот что у нас получилось (рис. 4.21). Немного доработав детали страницы, мы наконец-то получили дизайн, соответствующий устройству, на котором его просматривают. Мы больше не ограничены сеткой, макетом или типом, написанными первоначально для одного определенного диапазона разрешений. Наложенные поверх гибкого макета медиазапросы помогли нам решить проблемы, связанные с меньшими областями просмотра.
Рис. 4.21. Наш отзывчивый дизайн приобретает прекрасную форму, отлично масштабируясь даже на большом экране
Однако отзывчивый веб-дизайн – это не только дизайн, который хорошо смотрится на небольших экранах. При просмотре в максимизированном окне браузера также возникает ряд проблем: картинки растягиваются до невероятных размеров, строчки текста становятся слишком длинными, а сетка выходит за все мыслимые пределы (рис. 4.6–4.8). Следовательно, нам необходимо наложить определенные ограничения на дизайн при помощи свойства max-width, выраженного в em, или пикселях. Давайте думать об этом как о возможности сделать дизайн для другого диапазона разрешений.
Для начала познакомимся с еще одним медиазапросом:
@media screen and (max-width: 768px) {
…
}
@media screen and (max-width: 520px) {
…
}
@media screen and (min-width: 1200px) {
…
}
Первый запрос устанавливает потолок разрешения в 768 пикселей, то есть устройства и окна браузеров, ширина которых превышает ограничение max-width, будут попросту игнорировать вложенный в него CSS. Второй запрос повторяет действия первого, только для диапазона разрешения меньше 520px и при том же ограничении max-width.
В следующем запросе мы использовали свойство (min-width: 1200px) в качестве основного требования ко всем браузерам и устройствам. Если их ширина превышает 1200 пикселей, они будут применять вложенные стили; если нет – они могут спокойно делать свои дела и ни о чем не думать.
Ну что ж, засучим рукава и приступим к работе над макетом для широких экранов:
@media screen and (min-width: 1200px) {
.welcome,
.blog,
.gallery {
width: 49.375 %;
}
.welcome,
.gallery {
float: right;
margin: 0 0 40px;
}
.blog {
float: left;
margin: 0 0 20px;
}
}
На работающем сайте Robot or Not (http://responsivewebdesign.com/robot) вы найдете большое количество изменений, которые были внесены в макет, предназначенный для широкого экрана. Но эти три правила – основные. Мы присваиваем трем главным модулям контента (.welcome, blog, и .gallery) практически половину (49,375 %) ширины всей страницы. Затем мы передвигаем модули .welcome и .gallery вправо, а блог – влево. В результате получаем дизайн, который идеально подходит под широкие мониторы (рис. 4.22). Слишком длинные строчки стали короче, а блог, который представляет собой ключевой элемент контента, стал располагаться выше, что сделало его более доступным.
Другими словами, наш отзывчивый дизайн закончен.
Рис. 4.22. Давайте еще раз посмотрим на наш дизайн глазами пользователей больших экранов. Он выглядит прекрасно – и все благодаря медиазапросу
Кое-что по поводу совместимости
После того как мы уйму времени и страниц посвятили медиазапросам, настало время разрушить некоторые надежды, поскольку нам нужно поговорить о поддержке всего этого браузерами.
Хорошая новость заключается в том, что большинство современных десктопных браузеров поддерживают медиазапросы: среди них Opera 9.5+, Firefox 3.5+, браузеры на базе WebKit, такие как Safari 3+ и Chrome. Даже Internet Explorer 9 (http://bkaprt.com/rwd/32/) поддерживает медиазапросы (http://bkaprt.com/rwd/33/)! Кто-нибудь, ущипните меня.
Да и с мобильными браузерами дела обстоят неплохо. Медиазапросы поддерживают такие браузеры на базе WebKit, как Mobile Safari, webOS производства HP и Android. А по словам Питера-Пола Коха (http://bkaprt.com/rwd/34/), к ним не так давно присоединились Opera Mobile и Opera Mini. Что касается Windows Phone, с 2011 года на них устанавливается IE9 (http://bkaprt.com/rwd/35/), браузер, который обеспечивает повсеместную поддержку медиазапросов. Что не может не радовать.
К сожалению, «повсеместную» совсем не означает «универсальную». С десктопными браузерами старше тех, которые перечислены, нам не повезло. И Internet Explorer версии 8 и ниже также не поддерживает медиазапросы, а это значит, что досточтимый IE6 по-прежнему остается проблемой. И несмотря на то, что многие современные устройства с маленькими экранами обеспечивают приличную поддержку запросов, некоторые широко используемые браузеры (IE Mobile и те, которые стоят на старых BlackBerry) их не понимают (http://bkaprt.com/rwd/36/).
Так что картина не совсем отрадная. Но это вовсе не означает, что отзывчивая верстка – несбыточная мечта. Прежде всего, существует достаточно решений на базе JavaScript, которые компенсируют отсутствие поддержки старых браузеров. Недавно создана библиотека css3-mediaqueries.js library (http://bkaprt.com/rwd/37/), которая, как предполагается, «позволяет IE5+, Firefox 1+ и Safari 2 интерпретировать, тестировать и применять медиазапросы стандарта CSS3». Это еще очень ранняя, не до конца доработанная версия, и кому-то может показаться, что она недостаточно функциональная, но лично я считаю ее весьма работоспособной.
Недавно я воспользовался маленькой шустрой библиотекой respond.js (http://bkaprt.com/rwd/38/), разработанной Скоттом Джелом. Там, где css3-mediaqueries.js кажется перегруженной функциями, иногда даже слишком, respond выступает в роли заплатки (патча) при поддержке запросов min-width и max-width в старых браузерах. И он прекрасно работает практически для всех запросов, которые я написал на сегодня. Стоит упомянуть, что для того, чтобы этот скрипт работал как часы, необходимо добавить определенным образом форматированный CSS-комментарий в конце каждого запроса:
@media screen and (max-width: 768px) {
…
}/*/mediaquery*/
@media screen and (max-width: 520px) {
…
}/*/mediaquery*/
@media screen and (min-width: 1200px) {
…
}/*/mediaquery*/
Зачем он нужен? Часть кода css3-mediaqueries.js направлена на понимание структуры таблицы стилей: он открывает CSS и сразу же сообщает разницу между фигурной скобкой в конце CSS-правила и закрывающей скобкой в конце блока @media. Respond нет до этого никакого дела. Наоборот, он смотрит на этот небольшой комментарий и подхватывает запрос намного быстрее, чем другие скрипты.
Давайте добавим этот комментарий в конец каждого запроса сайта Robot or Not и вставим библиотеку respond.js в верхнюю часть страницы. Мы получим отзывчивый дизайн, который прекрасно работает в старых, не признающих медиазапросы браузерах, как, например, Internet Explorer 7 (рис. 4.23).
Рис. 4.23. Даже при отсутствии нашего патча для JavaScript более старые браузеры типа IE могут хоть как-то поддерживать медиазапросы
Я не особо полагаюсь на JavaScript и вам не советую. Мы можем спорить до посинения, но все равно нет никакой гарантии, что в браузере пользователя есть JavaScript. Может быть, этот пользователь работает на компьютере или ноутбуке, функции которого ограничены строгой службой IT-безопасности. А что касается мобильных браузеров… На мобильных устройствах не то что слабая поддержка JavaScript – на многих ее вообще нет.
В надежде справиться с этими проблемами, в пятой главе мы посвятим некоторое время обходным решениям, менее завязанным на JavaScript. Если вы не испытываете восторга от перспективы использования JavaScript, это вполне объяснимо. Однако для того, чтобы получить дизайн, не зависящий от устройства и разрешения, нужно строить его на гибкой основе.
Можно мне, как истинному фанату, издать еще ряд восклицаний во славу медиазапросов? С их помощью мы можем делать сайты, лучше отвечающие возможностям устройств, на которых их просматривают пользователи.
Однако сами по себе медиазапросы не делают дизайн отзывчивым. Они всего лишь накладываются поверх гибкой нефиксированной основы. В пользу этого подхода существует достаточно много аргументов, самый важный из которых следующий: гибкий дизайн может быть резервным вариантом для устройств и браузеров, не поддерживающих JavaScript и @media.
