Вы помните тот большой внушительный заголовок (рис. 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 () белого цвета (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. Однозначно над этим рисунком еще надо поработать
Ну что ж, наверное, и эту проблему можно решить, если она вас действительно беспокоит. Но прежде давайте снова взглянем на первоначальную разметку этого изображения, которое должно быть частью модуля слайд-шоу (и это еще предстоит сделать):
You can never be too sure.
Изрядный кусок 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, сделали маркированный список для навигации и присвоили им классы .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) {
…
}
@media screen and (max-width: 520px) {
.nav-primary {
float: left;
width: 100 %;
}
.nav-primary li {
clear: left;
float: left;
width: 48 %;
}
li#nav-rated,
li#nav-contact {
clear: right;
float: right;
}
.nav-primary a {
display: block;
padding: 0.45em;
}
}
Для еще более мелких экранов, с разрешением меньше 520 пикселей, мы передвинули каждый li внутри .nav-primary, присвоив второму и четвертому элементам свойство float: right. В результате мы получили более гибкую сетку 2 х 2, которая подстраивается под изменения размеров области просмотра, в отличие от display: inline (рис. 4.20).
Рис. 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 () вы найдете большое количество изменений, которые были внесены в макет, предназначенный для широкого экрана. Но эти три правила – основные. Мы присваиваем трем главным модулям контента (.welcome, blog, и .gallery) практически половину (49,375 %) ширины всей страницы. Затем мы передвигаем модули .welcome и .gallery вправо, а блог – влево. В результате получаем дизайн, который идеально подходит под широкие мониторы (рис. 4.22). Слишком длинные строчки стали короче, а блог, который представляет собой ключевой элемент контента, стал располагаться выше, что сделало его более доступным.
Другими словами, наш отзывчивый дизайн закончен.
Рис. 4.22. Давайте еще раз посмотрим на наш дизайн глазами пользователей больших экранов. Он выглядит прекрасно – и все благодаря медиазапросу