Давайте сделаем новый медиазапрос и немного подправим макет нашей страницы. Помните наш гибкий контейнер
#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
, благодаря чему изображение немного выходит за рамки с правой стороны.
Как назло, ни один из этих эффектов не будет работать при низком разрешении. Но я везучий парень. Так что давайте кое-что допишем в конце нашего медиазапроса: