1. Основы адаптивного веб-дизайна
Всего лишь несколько лет назад сайты могли создаваться с фиксированной шириной в расчете на то, что все конечные пользователи получат удобные условия работы. Эта фиксированная ширина (обычно 960 пикселов или около того) была не слишком велика для экранов ноутбуков, а пользователи, имеющие мониторы с высоким разрешением, просто видели с обеих сторон большие поля.
Но в 2007 году на телефонах iPhone компании Apple впервые появились по-настоящему удобные условия просмотра информации и условия доступа людей к веб-данным и работы с ними изменились навсегда.
В первом издании этой книги было отмечено, что «за 12 месяцев, с июля 2010-го по июль 2011 года, процент использования мобильных браузеров во всем мире вырос с 2,86 до 7,02».
В середине 2015 года в той же статистической системе (gs.statcounter.com) утверждалось, что данный показатель увеличился до 33,47 %. Для сравнения, в компании North America Mobile этот показатель достиг 25,86 %.
Использование мобильных устройств растет по любым показателям, а на другом краю шкалы в общую практику применения входят 27- и 30-дюймовые дисплеи. Как никогда ранее растет и разрыв между наименьшими и наибольшими экранами, на которых просматривается веб-содержимое. Благо есть решение, подходящее для постоянно расширяющейся арены браузеров и устройств. Нормальная работа сайта на множестве устройств и экранов возможна благодаря так называемому адаптивному дизайну, построенному на основе применения HTML5 и CSS3. Эта технология позволяет разметке и возможностям сайта подстраиваться под имеющееся окружение (размер экрана, тип ввода и возможности устройства или браузера).
Более того, адаптивный веб-дизайн, создаваемый с помощью HTML5 и CSS3, может быть реализован без необходимости использования конечных решений на серверной стороне.
Итак, вперед к неизведанному
Я надеюсь, что глава 1 поможет достичь одной из двух целей независимо от того, в новинку ли вам такие понятия, как адаптивный дизайн, HTML5 или CSS3, или вы в них неплохо разбираетесь.
Если HTML5 и CSS3 уже используются вами для адаптивной веб-разработки, эта глава позволит быстро вспомнить их основы. А если вы новичок в этом деле, воспринимайте ее в качестве своеобразного курса молодого бойца, охватывающего все с самого начала, так что данная глава пригодится всем без исключения.
К концу главы будет рассмотрено все необходимое для создания полностью адаптивной веб-страницы.
А зачем тогда остальные девять глав? Это также станет понятно к концу главы.
В текущей главе будут рассмотрены следующие вопросы:
• определение адаптивного веб-дизайна;
• способы настройки уровней поддержки браузеров;
• краткий обзор инструментальных средств и текстовых редакторов;
• создание первого адаптивного примера — простой страницы, созданной с использованием HTML5;
• важность метатега viewport;
• способ масштабирования изображений под их контейнер;
• написание медиазапросов CSS3 для создания контрольных точек дизайна;
• несовершенство нашего простого примера;
• почему мы находимся всего лишь в самом начале пути.
Определение адаптивного веб-дизайна
Понятие «адаптивный веб-дизайн» было введено Итаном Маркоттом (Ethan Marcotte) в 2010 году. В своей новаторской статье на сайте A List Apart (/) он свел воедино три уже существовавшие на тот момент технологии (гибкий макет на основе сетки, подстраиваемые по размеру изображения и элементы мультимедиа, а также медиазапросы) в единый унифицированный подход, который он назвал адаптивным веб-дизайном.
Адаптивный веб-дизайн в кратком изложении. Адаптивный веб-дизайн является представлением веб-содержимого в наиболее удобном формате для окна просмотра и устройства, обращающегося за этим содержимым.
На ранней стадии развития наиболее характерным для адаптивного дизайна было построение, начинающееся с «рабочего стола», то есть дизайна с фиксированной шириной. Затем, чтобы этот дизайн работал на экранах меньшего размера, содержимое автоматически переформатировалось или удалялось. Но процесс не стоял на месте, и стало понятно, что все, от дизайна до содержимого и разработки, получается намного лучше, если действовать в обратном направлении, начиная с небольших экранов и работая по нарастающей.
Прежде чем вникать во все это, я хочу рассмотреть два вопроса, касающиеся поддержки браузера, а также текстовых редакторов и инструментальных средств.
Установка уровней поддержки браузеров
Благодаря популярности и возможности повсеместного использования адаптивного веб-дизайна теперь стало намного легче торговать с клиентами и ключевыми партнерами. Некоторые представления об адаптивном веб-дизайне сложились уже у большинства людей. Понятие единого кода, способного работать практически на всех устройствах, становится весьма привлекательным.
При запуске проекта с адаптивным дизайном почти всегда возникает вопрос поддержки со стороны браузеров. При наличии столь широкого спектра браузеров и устройств вряд ли имеет смысл реализовывать полную поддержку изменений каждого отдельно взятого браузера. Вероятно, сдерживающим фактором является время, возможно — деньги. А может быть, и то и другое.
Как правило, чем старее браузер, тем больший объем работы и кода требуется для достижения желаемого результата или выравнивания эстетического восприятия с тем, которое пользователь получает при работе с современными браузерами. Поэтому рациональнее иметь менее вариативный и благодаря этому более быстродействующий код за счет распределения создаваемых впечатлений по уровням, обеспечивая получение самых совершенных визуальных эффектов и возможностей только на наиболее восприимчивых к ним браузерах.
В предыдущем издании этой книги некоторое время уделялось рассмотрению вопросов обслуживания очень старых браузеров, работающих исключительно на настольных компьютерах. В новом издании тратить время на это мы не будем.
В середине 2015 года мне уже приходилось писать о том, что времена браузеров Internet Explorer 6, 7 и 8 прошли. Даже IE 9 на всемирном рынке браузеров занимает весьма скромные 2,45 % (у IE 10 только 1,94 %, а у IE 11 уже более привлекательный показатель, равный 11,68 %). Если вам не остается ничего другого, как вести разработку под Internet Explorer 8 и более ранние версии, то я вам искренне сочувствую и заявляю, что ничего особо полезного из этой книги вы для себя не почерпнете.
Все остальные должны объяснить своему клиенту или заказчику, финансирующему проект, ошибочность разработки под скудные по своим возможностям браузеры и причины, по которым выделение времени и ресурсов преимущественно на разработку под современные браузеры и платформы во всех отношениях имеет более определенный финансовый смысл.
Но в конечном счете реальный вес имеет только ваша собственная статистика. За исключением экстремальных ситуаций, создаваемые нами сайты должны работать как минимум на каждом из самых распространенных браузеров. Кроме основных функциональных возможностей, для каждого веб-проекта имеет смысл заранее определить, на каких платформах нужно в полной мере создать наилучшие впечатления от его работы, а на каких вполне возможно будет согласиться на визуальные или функциональные отступления.
Вы также поймете, что на практике легче начинать с представления, создаваемого самым простым, базовым уровнем, и заниматься его усложнением (этот подход называется постепенным усложнением), чем подходить к решению проблемы с противоположной стороны — заниматься сначала созданием представления самого высокого уровня, а затем предпринимать попытки отступления для работы на платформах с более скромными возможностями (этот подход называется постепенным упрощением).
Чтобы пояснить причину, по которой это важно знать заранее, подумайте о том, что, если вам не повезет и 25 % посетителей вашего сайта будут пользоваться, к примеру, Internet Explorer 9, придется учесть, какие функции поддерживаются этим браузером, и подстраивать свое решение под эти качества. Те же меры станут необходимы, если большой контингент ваших пользователей посещает сайт с устаревших платформ мобильных телефонов, таких как Android 2. Что именно рассматривать в качестве базового представления, будет сильно варьироваться в зависимости от проекта.
Если подходящие данные недоступны, то для определения того, нужно ли тратить время на разработку версии под конкретную платформу или браузер, я прибегаю к простому логическому приему: если стоимость разработки под браузер X и дальнейшей поддержки превышает выручку или выгоду, создаваемую пользователями браузера X, то вести разработку конкретных решений под браузер X не стоит.
Надо реже задаваться вопросом о том, возможно ли вести подгонку под устаревшую платформу или браузер, и чаще спрашивать себя о целесообразности этого.
Если при рассмотрении вопроса о том, какие функции какими платформами и версиями браузеров поддерживаются, вы еще не ознакомились с сайтом , я настоятельно советую вам сделать это. Там предоставляется весьма простой интерфейс для выявления, поддержкой какого браузера пользуются интересующие нас функции.
Краткая справка по инструментарию и текстовым редакторам. Неважно, какими именно текстовым редактором или IDE-системой вы пользуетесь для создания своих адаптивных веб-конструкций. Если самые простые текстовые редакторы позволяют вам успешно записывать код HTML, CSS и JavaScript, значит, все в порядке. Аналогично этому нет никакой особой оснастки, играющей важную роль в получении на выходе адаптивного веб-дизайна. Фактически вам нужно лишь что-то позволяющее записывать код HTML, CSS и JavaScript. Чему вы отдадите предпочтение, Sublime Text, Vim, Coda, Visual Studio или Блокноту, не играет практически никакой роли. Работайте в той среде, которая вас больше всего устраивает.
Тем не менее следует знать, что, в отличие от прежних времен, сейчас имеется множество инструментальных средств (зачастую бесплатных), способных существенно облегчить выполнение рутинных, затратных по времени задач создания сайтов. Например, CSS-процессоры (Sass, LESS, Stylus, PostCSS) способны помочь с организацией кода, с переменными, в работе с цветовыми решениями и арифметикой. Такие средства, как PostCSS, способны также автоматизировать решение трудоемких и неприятных задач, например установку в коде CSS префиксов производителей. Кроме того, проверочные средства могут сравнить ваш код HTML, JavaScript и CSS со стандартами, по которым вы работаете, сэкономив массу времени на выявление опечаток и синтаксических ошибок.
Постоянно появляются все новые и новые инструментальные средства с более совершенными свойствами. Поэтому, какие бы актуальные и полезные средства ни упоминались в настоящее время, следует иметь в виду, что где-то рядом на выходе уже есть что-то более интересное. Следовательно, в своих примерах мы не можем полагаться на что-либо иное, кроме стандартов на основе HTML и CSS. Но вы можете воспользоваться доступными средствами для создания своей интерфейсной части кода как можно быстрее и надежнее.
Первый пример придания адаптивности
В начале главы я обещал, что к ее завершению вы узнаете обо всем необходимом для создания полностью адаптивной веб-страницы. До сих пор вокруг этого вопроса велись лишь досужие разговоры. Настало время выйти на прогулку.
Примеры программного кода
Все примеры кода из этой книги можно загрузить по адресу rwd.education/download.zip или через GitHub на сайте . Имейте в виду, что окончательные версии отдельных примеров, приводимых в главе, имеются только в загружаемом коде. Так, если загрузить примеры кода из главы 2, они будут иметь тот вид, в котором приводятся в конце данной главы. В отличие от текста самой главы, в загружаемых примерах кода никаких промежуточных состояний не приводится.
Наш исходный файл HTML
Начнем с простой структуры HTML5. Не обращайте внимания на предназначение абсолютно каждой строки (особенно на содержимое контейнера <head>, которое более подробно будет рассматриваться в главе 4).
Предлагаю пока сконцентрироваться на элементах внутри тега <body>. Я абсолютно уверен, что вы не увидите там ничего необычного: всего лишь несколько div-контейнеров, символ логотипа, изображение (симпатичная булочка), один-два текстовых абзаца и список ингредиентов.
Вам будет представлена сокращенная версия кода. Для краткости я удалил из показанного далее кода текстовые абзацы, поскольку нас интересует лишь структура. Но вы должны знать, что это рецепт и описание способа изготовления булочек, относящихся к типично британской выпечке.
Если есть желание просмотреть весь файл HTML, его можно загрузить с сайта rwd.education:
<!doctype html>
<html class="no-js" lang="en">
<head>
<meta charset="utf-8">
<title>Our first responsive web page with HTML5 and CSS3</title>
<meta name="description" content="A basic responsive web page
– an example from Chapter 1">
<link rel="stylesheet" href="css/styles.css">
</head>
<body>
<div class="Header">
<a href="/" class="LogoWrapper"><img src="img/SOC-Logo.png" alt="Scone O'Clock logo" /></a>
<p class="Strap">Scones: the most resplendent of snacks</p>
</div>
<div class="IntroWrapper">
<p class="IntroText">Occasionally maligned and
misunderstood; the scone is a quintessentially British classic.</p>
<div class="MoneyShot">
<img class="MoneyShotImg" src="img/scones.jpg" alt="Incredible scones" />
<p class="ImageCaption">Incredible scones, picture from Wikipedia</p>
</div>
</div>
<p>Recipe and serving suggestions follow.</p>
<div class="Ingredients">
<h3 class="SubHeader">Ingredients</h3>
<ul>
</ul>
</div>
<div class="HowToMake">
<h3 class="SubHeader">Method</h3>
<ol class="MethodWrapper">
</ol>
</div>
</body>
</html>
Изначально веб-страницы обладают гибкостью. Если открыть страницу примера даже в теперешнем ее состоянии (без медиазапросов) и изменить размер окна браузера, станет видно, что текст будет подвергнут необходимой перекомпоновке.
А как она себя поведет на других устройствах? При полном отсутствии CSS на iPhone получится следующее изображение.
Как видите, на iPhone она отобразилась точно так же, как и обычная веб-страница. Дело в том, что изначально iOS отображает веб-страницы шириной 980 пикселов и ужимает их в области просмотра.
Область просмотра браузера в технической терминологии известна как окно просмотра (viewport). Иногда это окно соответствует размеру экрана устройства, особенно в тех случаях, когда у пользователя есть возможность изменить размеры окна браузера. Поэтому впредь при обозначении пространства, доступного для нашей веб-страницы, как правило, будет использоваться эта, более точная терминология.
Эта заранее предполагаемая проблема легко решается путем добавления в <head>-контейнер следующего фрагмента кода:
<meta name="viewport" content="width=device-width">
Фактически этот метатег с именем viewport не считается стандартным способом указания браузеру способа отображения страницы (хотя и является стандартом де-факто). В данном случае наш метатег viewport представляет собой четкое предписание «отобразить содержимое во всю ширину экрана устройства». Легче, наверное, просто показать вам действие этой строки кода на воспринимающих ее устройствах.
Отлично! Теперь тест отобразился и разлился до более естественного размера. Пойдем дальше.
Различные настройки и сочетания метатега (и стандарты, послужившие основой для версии подобных функциональных возможностей) будут рассмотрены в главе 2.
Укрощение изображений
Как говорится, лучше один раз увидеть, чем сто раз услышать. Это относится и к булочкам на нашей взятой для примера странице, на которой изображение всей этой красоты пока что отсутствует. Я собираюсь поместить изображение булочки ближе к началу страницы в качестве своеобразной приманки для пользователей, чтобы им захотелось прочитать ее содержимое.
Увы! Весьма привлекательное, но довольно крупное изображение (шириной 2000 пикселов (px)) заставило страницу показать лишь часть картинки. Нужно исправить положение. Можно, конечно, задать с помощью CSS фиксированную ширину изображения, но перед нами стоит несколько иная задача: мы хотим, чтобы изображение масштабировалось под различные размеры экрана.
Например, на взятом нами для примера устройстве iPhone ширина составляет 320 пикселов, следовательно, для этого изображения можно установить ширину 320 пикселов, но что произойдет, если пользователь повернет экран? Окно просмотра теперь будет шириной не 320, а 480 пикселов. Нам повезло, поскольку получить подстраиваемые изображения, изменяющие масштаб под доступную ширину своего контейнера, можно с помощью всего лишь одной строчки кода CSS.
Теперь я собираюсь создать файл css/styles.css, ссылку на который дам в заголовке HTML-страницы.
Следующий код попадет в него в первую очередь. Обычно я устанавливаю и некоторые другие исходные настройки, речь о который пойдет в следующих главах, но для выполнения нашей задачи остановлюсь на том, что в начало файла помещу именно этот код:
img {
max-width: 100%;
}
Теперь после обновления страницы мы увидим что-то больше соответствующее нашим ожиданиям.
Правило, на котором основано свойство max-width, предполагает, что максимальная ширина всех изображений должна составлять 100 % их ширины (то есть они должны расширяться не более чем до 100 % своего размера). Когда содержащий изображения элемент (такой как body или div, внутри которого они находятся) меньше действительной ширины изображения, масштаб изображений будет просто подстроен, чтобы максимально занять доступное пространство.
А почему бы просто не воспользоваться свойством width: 100%?
Чтобы превратить изображения в подстраиваемые, можно также применить более широко востребованное свойство width, например width: 100%. Но в результате будет получен совершенно другой эффект. При использовании свойства width изображение будет показано с заданной шириной независимо от собственной ширины. В результате выполнения нашего примера получился бы логотип (также являющийся изображением), растянутый так, чтобы заполнить все 100 % своего контейнера. Когда контейнер намного шире изображения (как в случае с нашим логотипом), получается слишком растянутая картинка.
Замечательно. Теперь все располагается в соответствии с ожиданиями. Независимо от размера окна просмотра ничто теперь не выходит за границы страницы по горизонтали.
Но если посмотреть на страницу в более крупных окнах просмотра, основные стили как в прямом, так и в переносном смысле начинают восприниматься растянутыми. Взгляните на страницу примера при размере окна просмотра, составляющем около 1400 пикселов.
Вот так! Фактически страница начинает выглядеть растянутой уже при ширине примерно 600 пикселов. На данном этапе было бы полезно получить возможность кое-что подправить. Может быть, изменить размер изображения и расположить его рядом с одной из сторон. Может быть, изменить размеры некоторых шрифтов и фоновые цвета элементов.
И здесь нам сопутствует удача, поскольку все эти функциональные возможности мы можем получить без особого труда, привязав с помощью медиазапросов CSS требуемые настройки к нашим желаниям.
Ввод медиазапросов
Как выяснилось, когда окно просмотра выходит по ширине за 600 пикселов, текущая разметка начинает казаться растянутой. Воспользуемся медиазапросами CSS3 для коррекции разметки в зависимости от ширины экрана. Медиазапросы позволяют применять конкретные CSS-правила на основе целого ряда условий (например, ширины и высоты экрана).
Не устанавливайте значения конрольных точек равными ширине популярных устройств
Понятие «контрольная точка» используется для определения точки, в которой адаптивный дизайн должен претерпеть существенные изменения.
Когда люди только начинали применять медиазапросы, зачастую считалось, что контрольные точки в дизайне должны выстраиваться именно вокруг параметров наиболее популярных из имеющихся на то время устройств. Тогда эти контрольные точки обычно выстраивались вокруг параметров iPhone (320 × 480 пикселов) и iPad (768 × 1024 пикселов).
Но их выбор оказался неудачным, а в настоящее время он рассматривается как один из наихудших. Дело в том, что, поступая таким образом, мы ориентируем дизайн на конкретный размер экрана. А нам нужен адаптивный дизайн, то есть не то представление, которое неплохо смотрится только при конкретных размерах экрана, а то, которое не привязано к размеру экрана.
Поэтому позволим определять подходящие места для контрольных точек самому содержимому и дизайну. Может быть, исходная разметка начнет терять подобающий вид при ширине 500 пикселов и более, а может быть, 800 пикселов. Где именно нужно расставить контрольные точки, должно определяться дизайном вашего проекта.
Весь диапазон медиазапросов будет рассмотрен в главе 2, в названии которой и фигурирует этот термин.
Но чтобы наш простой пример не разрастался, мы сконцентрируемся на одном типе медиазапроса, касающегося минимальной ширины. Правила CSS внутри этого типа медиазапроса применяются только в том случае, если окно просмотра имеет минимальную заданную ширину. Точная минимальная ширина может указываться с применением целого набора различных единиц измерения длины, включая проценты, em, rem и px (пиксел). В CSS медиазапрос минимальной ширины записывается следующим образом:
@media screen and (min-width: 50em) {
/* стили */
}
Директива @media сообщает браузеру о начале медиазапроса, компонент screen (применять это объявление экрана в данной ситуации технически не обязательно, но более подробно работать с ним нам придется в следующей главе) сообщает браузеру, что правила должны применяться ко всем типам экранов, и компонент and (min-width: 50em) сообщает браузеру, что правила должны действовать для всех окон просмотра, чья ширина превышает 50 em.
совет
Я считаю, что первым, кто написал следующую фразу, был Брайан Ригер (Bryan Rieger) (): «Отсутствие носителя для медиазапросов фактически и является признаком первого медиазапроса».
Он имел в виду, что первыми правилами, которые нам нужно записать вне медиазапроса, должны быть базовые правила, которые мы затем будем наращивать для более соответствующих им устройств.
А пока нужно просто иметь в виду, что этот подход всего лишь сначала интеллектуально подкрепляет наименьший экран, позволяя постепенно детализировать уровни по мере того, как этого потребует дизайн.
Корректировка примера под более крупный экран. Мы уже выяснили, что наш дизайн начинает терять подобающий вид при ширине около 600 пикселов, или 37,5 rem.
Поэтому внесем в простой пример кое-что новенькое, определив разную разметку для разных размеров окна просмотра.
совет
Почти у всех браузеров текст имеет исходный размер 16 пикселов, поэтому ширину легко можно преобразовать в rem, разделив значение в пикселах на 16. Зачем нам это понадобится, мы узнаем в главе 2.
Для начала остановим чрезмерное разрастание соответствующего теме сайта изображения, удерживая его в правой части экрана. Затем можно поместить вводный текст в левую часть экрана.
После этого ниже его в левой части экрана можно расположить основную часть текста — рецепт, описывающий способ выпечки булочек, а справа в небольшом разделе, заключенном в прямоугольник, перечислить ингредиенты.
Все эти изменения могут быть получены относительно легко, нужно лишь поместить конкретные стили в медиазапрос. После добавления соответствующих стилей сайт приобретет следующий вид.
На экранах меньшего размера страница будет выглядеть так же, как и раньше, но как только окно просмотра окажется больше или равно 50 rem, страница будет настраиваться под новую разметку.
Добавленные стили разметки имеют следующий вид:
@media screen and (min-width: 50rem) {
.IntroWrapper {
display: table;
table-layout: fixed;
width: 100%;
}
.MoneyShot,
.IntroText {
display: table-cell;
width: 50%;
vertical-align: middle;
text-align: center;
}
.IntroText {
padding: .5rem;
font-size: 2.5rem;
text-align: left;
}
.Ingredients {
font-size: .9rem;
float: right;
padding: 1rem;
margin: 0 0 .5rem 1rem;
border-radius: 3px;
background-color: #ffffdf;
border: 2px solid #e8cfa9;
}
.Ingredients h3 {
margin: 0;
}
}
Получилось совсем неплохо, правда? Используя минимум кода, мы создали страницу, реагирующую на размер окна просмотра и предлагающую по мере необходимости желательную разметку. Добавлением всего лишь нескольких дополнительных стилей мы добились более привлекательного внешнего вида страницы.
Теперь, после всех добавлений, наша основная адаптивная страница на iPhone выглядит следующим образом.
А так она выглядит при ширине окна просмотра свыше 50 rem.
Все эти дополнительные визуальные украшения не добавляют понимания того, что происходит в смысле адаптируемости, поэтому здесь я их опустил, но если нужно просмотреть соответствующий код, его можно загрузить по адресу или .
При всей своей простоте этот пример включает в себя неотъемлемые части методологии построения адаптивного веб-дизайна.
Чтобы подтвердить важность всего рассмотренного, начните с базовых стилей, работающих на любом устройстве. Затем по мере роста размеров окна просмотра и/или возможностей постепенно наращивайте уровень пользовательского восприятия.
примечание
Полную спецификацию медиазапросов CSS Media Queries (Level 3) можно найти по адресу /.
А рабочий вариант CSS Media Queries (Level 4) можно найти здесь: /.
Несовершенство нашего примера
В этой главе были рассмотрены все важные составные части простой адаптивной веб-страницы, использующей свойства HTML5 и CSS3.
Но и вам и мне понятно, что задачи по созданию сайтов вряд ли сведутся к такому простому примеру адаптивного дизайна. И этим примером возможности создания такого дизайна совсем не ограничиваются.
К примеру, что делать, если захочется, чтобы страница реагировала на различные условия освещенности? А как насчет изменения размеров ссылок, когда люди используют различные указывающие устройства (к примеру, палец, а не указатель мыши)? А насчет возможностей простого перемещения визуальных элементов и добавления к ним эффектов анимации с использованием исключительно CSS?
Кроме этого, есть еще вопросы разметки. Как перейти к разметке страниц, имеющих большее количество смысловых элементов, таких как статья, раздел, меню и т. п., или как создать формы со встроенной проверкой, не требующие использования JavaScript? Что если захочется изменить визуальный порядок следования элементов для различных окон просмотра?
И не нужно забывать об изображениях. В этом примере у нас были подстраиваемые изображения, но что, если люди зайдут на страницу с мобильного телефона и им потребуется загрузка большого объема графики (шириной не менее 2000 пикселов), которая на их телефоне будет показана лишь частично? Страница станет загружаться намного медленнее, чем от нее требуется. Ведь есть же более подходящий способ?
А как насчет логотипов и значков? В данном примере использовались изображения формата PNG, но мы ведь запросто можем применить масштабируемую векторную графику (Scalable Vector Graphics (SVG)), чтобы получить качественное изображение, которое не зависит от разрешения экрана просмотра.
Надеюсь, у вас есть время на учебу, поскольку ответы на все эти вопросы будут даны в следующих главах.
Резюме
Мы неплохо поработали, и теперь вам известны и понятны самые важные моменты, необходимые для создания полностью адаптивной веб-страницы. Но как мы только что выяснили, совершенству нет предела.
Все идет своим чередом. Мы хотим не просто получить возможность создания надлежащих веб-проектов с адаптивным веб-дизайном, а создавать лучшие в своем роде представления. Так добьемся же этого.
Для начала мы усвоим все, что могут предложить нам медиазапросы уровней CSS3 и CSS4 (Level 3 и Level 4 CSS Media Queries). Мы уже видели, как веб-страница может подстраиваться под ширину окна просмотра, но уже сейчас способны на более серьезные дела, и вскоре ваши браузеры станут демонстрировать гораздо более интересные возможности. Давайте двигаться дальше и смотреть на все это своими глазами.
