Отзывчивый веб-дизайн - [18]

с другими свойствами 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. Однозначно над этим рисунком еще надо поработать}

Ну что ж, наверное, и эту проблему можно решить, если она вас действительно беспокоит. Но прежде давайте снова взглянем на первоначальную разметку этого изображения, которое должно быть частью модуля слайд-шоу (и это еще предстоит сделать):

>

…

• Previous
• Next

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. Поэтому мы отменяем масштабирование