Итан МаркоттОтзывчивый веб-дизайнСерия «Актуальные книги длятех, кто создает сайты», книга 1

Текст предоставлен издательствомhttp://www.litres.ru/pages/biblio_book/?art=3744275

Отзывчивый веб-дизайн: Манн, Иванов и Фербер; Москва; 2012ISBN 978-5-91657-385-5

АннотацияИнтернет вышел за границы мира стационарных

компьютеров, и сегодня можно с уверенностью сказать,что в течение нескольких лет лидирующей формойдоступа в Сеть станут устройства с маленькими экранами.

Перед вами первое и единственное практическоеруководство, которое в пошаговой форме дает ответна вопрос, как сделать сайт максимально удобнымдля всех его посетителей, независимо от того,на каком устройстве они будут его просматривать.Оно содержит рекомендации, как избежать наиболеераспространенных ошибок и решить большинствопроблем, с которыми сталкиваются современныеинтернет-пользователи. Кроме того, в нем вы найдете

программные коды, которые позволят применить напрактике все предложенные разработки.

СодержаниеОт научного редактора 8Предисловие 101. Наша отзывчивая сеть 12А теперь пристегните ремни 19Отзывчивая архитектура 22Путь вперед 25

Ингредиенты 262. Гибкая сетка 31Гибкие шрифты 37

Контекстное восстановление 42От гибких шрифтов к гибкой сетке 47

Создание гибкой сетки 48От пикселей к процентам 57

Гибкие поля и отступы 63Не продохнуть… 64Немного отрицательных значений 75Гибко двигаемся дальше 81

3. Гибкие изображения 82Назад к разметке 83Гибкие изображения 88Если бы все было так просто… 93

Max-width в Internet Explorer 94…И здесь становится понятно, чтоWindows нас ненавидит

97

Да здравствует герой-победительAlphaImageLoader!

102

Гибкие повторяющиеся фоновыеизображения

106

Полностью гибкие фоновыеизображения?

114

Как научиться любить Overflow 116Проблемы с контентом 119Гибкие сетки и изображения как древопознания

122

4. Медиазапросы 123Приступим к лечению 124

Расстановка акцентов 125Маленькая сетка, большие проблемы 128Широкоэкранные неприятности 133

Насущные проблемы 136Навстречу отзывчивости 137

Знакомьтесь: медиатипы 138Неправильное распределение типов 141Знакомство с медиазапросами 143Познакомьтесь с характеристиками 145Знай свои характеристики 147

Более отзывчивый робот 151В компании с viewport 152

Медиазапросы в действии 156Все дело в деталях 162Отворяй ворота! 178

Кое-что по поводу совместимости 182Зачем это нужно? 187

Ограничения по мере необходимости 1895. Как стать отзывчивым 197Все дело в контексте 198

Определение целей пользователей 203Знакомьтесь: «Сначала мобильные» 206Навстречу отзывчивому процессуразработки

208

Определяем разрешение 211Итеративный совместный дизайн 213Интерактивный анализ дизайна 221

Ответственный подход к отзывчивомудизайну

229

«Сначала мобильные» и медиазапросы 234Концепция прогрессивного улучшения 241

Работа с JavaScript 244Загружаем контент не спеша, но с умом 250Дальнейшие улучшения 255

Вперед! Будь отзывчивым! 258Благодарности 260Приложение 263

Глава 1 263Глава 2 264Глава 3 265Глава 4 266Глава 5 268

Рекомендуемая литература 271Помощь онлайн 272Об авторе 274

Итан МаркоттОтзывчивый веб-дизайн

От научного редактора

Когда вы в последний раз выходили в Интернет со

своего планшетника, электронной читалки или теле-фона? Вчера? Сегодня утром, просматривая новостиза чашкой кофе?

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

«Почему же Интернет такой неповоротливый?» –спросите вы. Но это не так: Сеть меняется каждыйдень. Дизайнеры уже давно научились делать сайты,которые отлично выглядят и на широкоформатном мо-ниторе, и на экране мобильного телефона. И вот чтоинтересно – нужно для этого не так уж много. Не стоитписать кучу кодов для каждого мобильного устройства,тратить ресурсы на доработку под постоянно расту-щий ассортимент (попробуй за ним угнаться, когда тогогляди мы будем заказывать домой продукты с экрана,

встроенного прямо в холодильник).Об этом говорит и автор «Отзывчивого веб-дизай-

на». Он погружает вас в мир адаптивных веб-сайтов– сайтов, которыми удобно пользоваться независимоот того, какое устройство сейчас в вашем распоряже-нии. Сегодня эта концепция – не прихоть, а важныйтренд развития Сети. И речь идет не просто о «тяну-щемся» сайте, а о его «умном» приспособлении к лю-бому устройству. Пользователю, который удобно рас-положился за большим экраном, вы покажете сразунесколько колонок текста. Тому же, кто зашел на вашсайт с iPhone, – лишь тот контент, который нужен емув дороге.

Адаптирован ли ваш сайт к мобильным устрой-ствам? Не теряете ли вы клиентов лишь оттого, что имнеудобно заходить на него с планшетника или читал-ки? Помогите посетителям вашего сайта – адаптируй-те его для них. О том, как это лучше всего сделать, выузнаете из книги Итана Маркотта.

Александр Сарычев, улучшающий сайты,аналитик компании «ЛидМашина. ру»

Предисловие

Язык способен творить чудеса. В английском языке

у слова glamour («гламур», «очарование») имеются идругие значения – «магия» или «чародейство», а про-исходит оно от слова grammar («грамматика»). Из всехчудес, творимых языком, самое волшебное и потряса-ющее – способность присваивать имена.

История веб-дизайна, хоть и недолгая, уже про-демонстрировала нам преобразующую силу языка.Джеффри Зельдман подарил нам термин «веб-стан-дарты», а Джесси Джеймс Гарретт изменил природувзаимодействия в Сети, придумав технологию Ajax.

Итан Маркотт, изобретя термин «отзывчивый веб-дизайн» (responsive web design), также сотворил сво-его рода волшебство. Такие технологии, как «резино-вые» сетки и изображения или медиазапросы, суще-ствовали и до него, но Итан объединил их и изменилсамо наше представление о веб-дизайне.

Итан – прекрасный рассказчик. Он мог бы стать иде-альным автором книги об отзывчивом веб-дизайне. И,что самое замечательное, он ее уже написал!

Если вы надеетесь найти здесь советы и рекоменда-ции, которые помогут вам придать своим сайтам внеш-ний лоск, тогда эта книга не для вас – этот маленький

шедевр куда глубже.Когда вы прочтете книгу (а это не займет у вас много

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

Итан Маркотт – самый настоящий волшебник, поэто-му расслабьтесь и будьте готовы поддаться его чарам.

Джереми Кит, дизайнер и веб-разработчик,автор книги «HTML5 для веб-дизайнеров»

1. Наша отзывчивая сеть

«Есть что-то, что не любит

ограждений…»Роберт Фрост, «Починка стены»

Когда я начал писать эту книгу, я вдруг понял, чтопонятия не имею, в каком именно виде вы будете еечитать. По крайней мере, гарантировать, что вы будетечитать ее, перелистывая бумажные страницы, я не мо-гу. Может, вы сидите за столом и читаете ее электрон-ную версию на мониторе компьютера. Может, едете наработу и читаете ее на экране телефона или планше-та. А может, даже и не читаете, а слушаете то, что вамзачитывает компьютер.

Я вообще очень мало о вас знаю.Издательское дело переняло одну из главных осо-

бенностей Сети – ее гибкость. Дизайнер и книгоиз-датель Крэйг Мод считает, что издательская деятель-ность быстро входит в фазу «постартефакта» (http://bkaprt.com/rwd/1/), что цифровой век, в который мы жи-вем, диктует свои условия, и мы должны пересмотретьсамо понятие «книга».

Конечно, веб-дизайнеры уже в течение некоторо-го времени пытаются разобраться с этим. По сути, внашей профессии собственных «артефактов» еще не

было. Ведь то, что мы производим, нельзя потрогать,сохранить, передать своим детям. Но, несмотря набесплотный характер нашей работы, посмотрите, ка-кими терминами мы постоянно пользуемся: «шапка»,«пробел», «просвет». Все эти слова пришли непосред-ственно из мира полиграфии: мы достали их с дальнейполки, стряхнули пыль и успешно используем в нашемновом цифровом мире.

Некоторые из результатов такой «вторичной пере-работки» были совершенно оправданными. Что ни го-вори, привычка – вторая натура: переезжая в другойгород или устраиваясь на новую работу, мы, конечноже, прихватываем с собой старый опыт и накладываемего на новые обстоятельства, чтобы ориентироватьсяв новой действительности. А поскольку веб-дизайн –довольно-таки молодая сфера деятельности, для не-го вполне естественно заимствовать некоторые терми-ны из знакомого мира. История графического дизайнаохватывает несколько столетий, и было бы нелепо неиспользовать его язык для формирования нашей отра-сли.

Но мы обязаны миру полиграфии намного большим,нежели слова и термины. Не все помнят об этом, номы позаимствовали из него понятие «холст» (рис. 1.1).Любая работа в сфере художественного творчестваначинается с выбора холста: художник использует листбумаги или кусок ткани, скульптор выбирает каменную

глыбу. Независимо от того, что намерен сделать худож-ник, его первый творческий акт – выбор холста. Ещедо первого мазка кисти или удара зубила холст задаетпроизведению искусства параметры и форму, ширинуи высоту будущей работы, определяет ее границы.

Рис. 1.1. Холст, даже пустой, создает ограничения для работы худож-

ника

Веб-дизайнеры стараются подражать этому процес-су. Мы даже используем то же слово: в нашем лю-

бимом редакторе мы создаем «холст» – чистый доку-мент с определенной шириной, высотой, параметра-ми и формой. Однако у веб-дизайнеров имеется су-щественная проблема: мы находимся на удалении отпользователя и его окна браузера со всеми свойствен-ными только ему несоответствиями и недостатками(рис. 1.2). Давайте посмотрим правде в глаза: как толь-ко проект становится доступным онлайн, все начина-ет зависеть от человека, который его просматривает, –от выбранного им шрифта, цветопередачи монитора,формы и размера окна браузера.

Рис. 1.2. Наш холст – окно браузера

Сталкиваясь с такой неопределенностью и гибко-стью, мы начинаем устанавливать ограничения: зада-ем размеры шрифтов в пикселях или создаем макеты сфиксированной шириной, с учетом минимального раз-решения экрана. Установка таких ограничений немно-

го напоминает выбор того самого холста – они опреде-ляют параметры будущей работы и придают стабиль-ность, которая защищает от изменчивости, изначаль-но присущей Сети.

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

Рис. 1.3. Даже небольшое отклонение от «идеальных» параметров

может негативно сказаться на впечатлении пользователя…

Рис. 1.4. …а также на самом нашем бизнесе и отношении клиентов.

(«Что скрывается за буквами Reg?» – спросите вы. А это просто обрезан-

ная ссылка на страницу регистрации.)

А теперь пристегните ремни

Более десяти лет назад Джон Олсопп написал ста-

тью A Dao of Web Design («Дао веб-дизайна») (http://bkaprt.com/rwd/3/), и если вы не читали ее раньше, топросто обязаны прочитать сейчас (серьезно, я готовподождать). Это мое любимое эссе о веб-дизайне, ионо столь же актуально сейчас, как и тогда, когда егонаписали.

Джон считает, что:Контроль, которым обладает дизайнер, когда

работает с печатным носителем, и о котороммечтает, когда работает в вебе, есть попростуфункция ограничений, навязываемая печатнойстраницей. Нам следует радоваться тому,что Сеть не имеет подобных ограничений, исоздавать дизайн с расчетом на гибкость. Новначале мы должны в полной мере «оценитьплюсы и минусы такого положения вещей.

Конечно, Джон писал это во времена становленияСети, когда дизайнеры переносили принципы печатно-го дизайна в новую молодую среду. Но бо́льшая частьсказанного актуальна и сегодня. Ведь в наши дни Сетьстала еще более гибкой.

Как бы там ни было, мы вступили в свой собствен-ный переходный период. Разнообразие браузеров при-

обретает впечатляющие масштабы, а устройства ста-новятся одновременно и миниатюрнее, и крупнее. Пооценкам специалистов, в течение нескольких ближай-ших лет лидирующей формой доступа в Сеть станутустройства с маленькими экранами, при этом совре-менные игровые консоли позволят работать в Сети наширокоформатных экранах. В последнее время всебольше пользователей заходят в Интернет с планше-тов, то есть у нас появилась еще одна форма доступа– не мобильная и не стационарная, а нечто среднее.

Короче говоря, сейчас нам приходится считаться сгораздо бо́льшим количеством устройств, типов входаи разрешений. Сеть вышла за пределы мира стацио-нарных компьютеров, и назад дороги нет.

К сожалению, ранние попытки проектирования по-разительно напоминали наши старые подходы, то естьмы по прежнему пытались установить ограничения,чтобы как-то компенсировать неопределенность рабо-ты в Сети. Несколько месяцев назад моя подруга при-слала мне ссылку на статью, которую она только чтопрочитала с помощью своего телефона:

http://www.bbc.co.uk/news/mobile/science-environment-13095307

Видите директорию /mobile/? Владельцы сайтаиспользовали для доступа к статье с мобильныхустройств отдельный адрес, установив для него шири-ну страницы в 320 пикселей. Посетители сайта, полу-

чившие ссылку на него через Twitter, Facebook или попочте, могут просматривать его только в таком, пред-назначенном для маленьких экранов виде (независи-мо от того, на каком устройстве они изучают матери-ал). Для меня читать эту статью на стационарном ком-пьютере было сплошным мучением.

Это вовсе не значит, что мобильные сайты никомуне нужны или что для их создания нет никаких коммер-ческих оснований. Но я искренне считаю, что предста-вление контента в зависимости от устройства – подходесли не проигрышный, то, во всяком случае, нежизне-способный. За последние несколько лет мы уже поня-ли, что не в состоянии угнаться за темпами развитиятехнологий. Мы что, действительно собираемся под-страиваться под каждый новый браузер или устрой-ство?

Нет? Тогда какие у нас есть еще варианты?

Отзывчивая архитектура

Я всю жизнь увлекался архитектурой. Для меня как

веб-дизайнера особую притягательность имеет имен-но то обилие ограничений, которыми, как мне кажет-ся, наслаждаются архитекторы: каждый этап архитек-турного процесса – от эскиза до плана, от фундамен-та до фасада – неуклонно становится все более жест-ким и все менее изменчивымым. Английский архитек-тор Кристофер Рен однажды написал, что архитекту-ра устремлена в вечность, и в этих словах заключенавеликая истина, ведь творческие решения архитекто-ра останутся неизменными на десятилетия, если не навека.

Проведя лишь день наедине с Internet Explorer, на-чинаешь думать, что такое постоянство действительнопрекрасно.

Однако в последние годы возникла относительно но-вая дисциплина, которая получила название «отзыв-чивая архитектура» и которая бросила вызов незыбле-мости, лежащей в основе архитектуры как таковой. Этоочень молодая дисциплина, но как более интерактив-ная форма она уже громко заявила о себе в несколь-ких направлениях.

К примеру, проводятся эксперименты с поверхно-

стями, которые реагируют на голос (http://bkaprt.com/rwd/5/), и с жилыми пространствами, которые могуттрансформироваться, подстраиваясь под пользовате-лей (http://bkaprt.com/rwd/6/). Не так давно придуманатехнология «умного» стекла, которое по желанию кли-ента, решившего отгородиться от внешних раздражи-телей, становится матовым (рис. 1.5).

Рис. 1.5. То видно, то не видно: «умное» стекло может автоматически

становиться матовым

А одна немецкая дизайнерская компания, исполь-зуя автоматические системы и эластичные материалы,создала «стену», способную изгибаться, расширяться

и менять форму, когда к ней приближается человек(рис. 1.6).

Рис. 1.6. Это не просто привлекательная художественная инсталля-

ция. Стена действительно может чувствовать присутствие человека и ре-

агировать на его приближение

Вместо того чтобы создавать пространства, которыевлияют на поведение находящихся в них людей, при-верженцы нового подхода предлагают пространства,взаимодействующие с человеком.

Путь вперед

Меня восхищает то, что архитекторы пытаются пре-

одолеть ограничения, изначально присущие их дея-тельности. Веб-дизайнеры же, сталкиваясь с много-образием новых устройств и окружений, вынужденыпреодолевать ограничения, которые мы сами и нало-жили на свойственную Сети гибкость.

Мы должны пойти другим путем.Вместо того чтобы создавать отдельный дизайн для

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

Короче говоря, нам следует практиковать отзывчи-вый веб-дизайн. Мы можем воспользоваться присущейСети гибкостью, не отказываясь при этом от необходи-мого нам контроля. Все, что нам для этого нужно, – вне-дрить в нашу работу технологии, основанные на стан-дартах, и несколько изменить собственное отношениек веб-дизайну.

Ингредиенты

Итак, что же нужно для создания отзывчивого дизай-

на? Если мы говорим о разработке макета страницы,нам потребуются три основных компонента:

1. Гибкий макет на основе сетки (flexible, grid-based layout).

2. Гибкие изображения (flexible images).3. Медиазапросы (media queries), модуль специ-

фикации CSS3.В следующих трех главах мы последовательно рас-

смотрим эти элементы, которые и сделают наш подходк веб-дизайну более отзывчивым. В процессе изуче-ния мы создадим дизайн, способный адаптироватьсяк ограничениям окна браузера или устройства, на ко-тором он будет просматриваться, то есть дизайн, прак-тически полностью отвечающий потребностям пользо-вателя.

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

обычно трачу на обед, но если там есть хоть один кос-мический корабль – я счастлив.

Во всех научно-фантастических фильмах, хорошихили плохих, есть любимый авторами данного жанрасюжетный прием: тайный робот. Вы наверняка виде-ли хоть один из подобных фильмов. Они всегда на-чинаются с того, как группа мужественных авантюри-стов во главе с честным героем, вооруженным содер-жательными остротами и/или непреклонной решимо-стью, отправляется на битву с неким злом. Но в их ря-ды затесался… тайный робот (звучит зловещая музы-ка). Это хитрое, дьявольски бездушное существо, сде-ланное из холодной стали и еще более холодных рас-четов, но похожее на человека, и имеет оно одну чет-кую и подлую цель: подорвать нашу героическую груп-пу изнутри.

Разоблачение робота – это кульминация всегофильма. Ясное дело, вы с самого начала знаете, ктогерой, а кто робот-шпион. Что касается остальных пер-сонажей, то приходится терзаться в догадках: кто жеиз них человек, а кто – тоже робот?

Лично для меня это никогда не было проблемой. Я,конечно, не говорю о Джонни 5 и C-3PO1, на которыхстоило только взглянуть, чтобы понять, что они явно нелюди. Я имею в виду тех, кто скрывает свою сущность

1 Роботы, герои фильма «Короткое замыкание» и саги о «Звездных вой-нах» соответственно. Здесь и далее прим. пер.

под синтетической кожей. Итак, я взял дело в свои ру-ки: чтобы хоть как-то помочь решить эту проблему инаучиться отличать друзей из крови и плоти от желез-ных врагов, я спроектировал небольшой сайт под на-званием Robot or Not («Робот или нет») (рис. 1.7).

Рис. 1.7. Дизайн сайта Robot or Not во всей красе

Согласен, может, этот вопрос никого, кроме меня, неволнует.

Но это на самом деле и неважно. На этом примерея просто покажу вам, как именно делается отзывчивыйсайт. На протяжении следующих нескольких глав мы свами будем разрабатывать сайт Robot or Not вместе,используя гибкие сетки, гибкие изображения и медиа-запросы.

Возможно, вас не сильно увлекло мое повествова-ние.

А может быть, вы уже устали от моей болтов-ни и хотите увидеть готовый продукт. Если так,тогда просто введите в адресной строке http://responsivewebdesign.com/robot/ и попробуйте его, какговорится, на ощупь.

Вы все еще здесь? Чудесно. Тогда начинаем.

2. Гибкая сетка

Один мой преподаватель в колледже как-то сказал,

что любое художественное действие – музыкальное,литературное или изобразительное – можно считатьответом на действие, ему предшествующее. Режиссе-ры шестидесятых сняли фильмы «Бонни и Клайд» и«Выпускник» в ответ на старые голливудские картины,такие как, например, «Звуки музыки». В «Потерянномрае» Джон Мильтон фактически помещает своих лите-ратурных предшественников в декорации ада – и этовряд ли можно считать тонкой насмешкой над их поэ-тическими идеалами. И если бы не музыка Дюка Эл-лингтона и Бенни Гудмена, Чарли Паркер, возможно,никогда бы и не затевал своих безумных эксперимен-тов с бибопом.

Люди искусства всегда спорили друг с другом. Это впервую очередь касается художников-модернистов се-редины ХХ века. Модернисты смотрели на творческоенаследие предшественников – романтиков конца XIXвека – с некоторым, мягко говоря, презрением. Для нихискусство романтиков было перегружено всей этой че-пухой – бесполезным украшательством, которое сво-дило на нет художественную ценность произведенияи не позволяло должным образом донести до зрителя

его смысл (рис. 2.1).

Рис. 2.1. Модернисты провозглашали отрыв от чрезмерно разукра-

шенного реализма Уильяма Блейка и Эжена Делакруа и переход к более

рациональному подходу Ханса Хофманна и Йозефа Мюллер-Брокманна

Реакция модернистов проявлялась различнымиспособами и охватывала практически все виды искус-ства. Так, в живописи это означало сведение картин доэкспериментов с линиями, формой и цветом. Графиче-ские дизайнеры того времени, такие как Ян Чихольд,Эмиль Рудер и Йозеф Мюллер-Брокманн, популяризи-ровали понятие типографской, или модульной, сетки– рациональной системы колонок и рядов, в которыеможно было поместить модули с контентом (рис. 2.2).А благодаря дизайнерам Хою Виню и Марку Болтонунам удалось адаптировать эту старую концепцию к по-требностям современного веб-дизайна.

Рис. 2.2. Типографская сетка, использующаяся для размещения со-

держимого и определения размеров страницы, – это мощный инстру-

мент, помогающий и дизайнеру, и читателю

В книге Grid Systems in Graphic Design («Систе-мы сеток в графическом дизайне») Мюллер-Брокманнназвал этот процесс «созданием типографского про-странства на странице», то есть разметкой сетки про-порционально размеру чистого листа бумаги.

Но графический дизайн отличается от веб-дизай-на одним ключевым моментом: размерами страницы.Наш же холст – окно браузера – может приниматьлюбую форму и размеры в соответствии с прихотями

читателя или размерами устройств, на которых этотхолст отображается.

Обычно первый слой нашего макета выглядит сле-дующим образом:#page{ width: 960px;margin: 0 auto;}То есть мы создали элемент в разметке, задали

его фиксированную ширину в CSS и расположили настранице по центру. Если же мы решили создать гиб-кую сетку, мы должны перевести дизайн, созданный вPhotoshop (рис. 2.3), во что-то более «резиновое», бо-лее пропорциональное.

С чего же начать?

Рис. 2.3. Созданный в Photoshop макет выглядит достаточно привле-

кательным, в отличие от сетки. Как можно сделать ее более гибкой?

Гибкие шрифты

Чтобы ответить на этот вопрос, давайте сыграем в

одну ролевую игру. Нет-нет, можете убрать реквизит, яговорю о чем-то более практичном, не имеющем отно-шения к игрищам «толкиенистов».

Представьте на мгновение, что вы – разработчикпользовательских интерфейсов. (Если вы и так раз-рабатываете пользовательские интерфейсы, то пред-ставьте себя еще и в пиратской шляпе.) Дизайнер извашей команды попросил вас преобразовать простоймакет в разметку и CSS. Вы бросаете быстрый взглядна макет, который он вам прислал (рис. 2.4).

Рис. 2.4. Эскиз для нашего упражнения. По-хорошему, повторить его

– минутное дело

Содержимое достаточно скромное, но даже неболь-шие проекты требуют пристального внимания к мело-чам. Итак, вы углубляетесь в изучение дизайна. Оце-

нив типы контента в макете, вы пишете следующийHTML-код:<h1>Achieve sentience with Skynet! <a

href="#">Read More &raquo;</a></h1>Заголовок с включенной в него ссылкой – прекрас-

ная основа для семантической разметки, не правдали? После обнуления стилей вы получаете в браузе-ре следующий результат (рис. 2.5). По чуть-чуть про-двигаемся вперед. Теперь мы можем начать добавлятьсвой стиль оформления. Давайте впишем в элементbody некоторые базовые правила:body {background-color: #DCDBD9;color: #2C2C2C;font: normal 100 % Cambria, Georgia,

serif;}

Рис. 2.5. Разметка без стилей. Именно так создается мечта (и веб-

сайт)

Ничего особенного: светло-серый фон (#DCDBD9)для всего документа и черный текст (#2C2C2C). И ко-нечно, характеристики шрифта – жирность (по умолча-нию обычная, normal) и семейство шрифтов с засеч-ками (Cambria, Georgia, serif).

Вы, вероятно, заметили, что кегль (размер шрифта)был установлен 100 %. Поступив таким образом, мыпривели базовый кегль к величине, принятой в браузе-ре по-умолчанию, который в большинстве случаев со-ставляет 16 пикселей. Теперь мы всегда сможем изме-нить кегль по отношению к этой относительной базовойвеличине с помощью единиц измерения em. Но преждечем мы это сделаем, давайте посмотрим, что у нас ужеполучилось (рис. 2.6).

Рис. 2.6. Применив одно простое правило CSS, мы можем придать

эскизу несколько другой вид

Удивлены, почему h1 не выглядит как нормальныйзаголовок? Мы используем обнуление стилей, нивели-рующее стили браузера по умолчанию для элементовHTML, чтобы обеспечить их соответствие в различныхбраузерах. Лично мне больше всего нравится способобнуления от Эрика Мейера (http://bkaprt.com/rwd/9/),но вы можете выбрать какой-нибудь другой, благо вы-бор сейчас достаточно большой.

В любом случае наш h1 выглядит таким малень-ким именно по этой причине: он наследует стиль fontsize 100 %, который мы задали родительскому эле-менту body, а установленный в браузере по умолча-нию кегль – 16 пикселей.

Теперь, если пиксели нас устраивают, мы можем пе-ревести значения из оригинал-макета непосредствен-но в CSS:h1 {font-size: 24px;font-style: italic;font-weight: normal;}h1 a {color: #747474;font: bold 11px Calibri, Optima, Arial,

sans-serif;letter-spacing: 0.15em;text-transform: uppercase;

text-decoration: none;}Нет ничего плохого или неправильного в определе-

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

Контекстное восстановление

Сейчас будет немного математики: берем целевое

значение кегля и делим на кегль (font size) его кон-тейнера, то есть контекста. В результате мы получаемжелаемый кегль, выраженный в относительных и до-статочно гибких единицах em.

Другими словами, относительный кегль можно рас-считать по следующей формуле:target ÷ context = result(Отвлечемся на минутку. Лично у меня слово «мате-

матика» вызывает немедленный и серьезный приступпаники. У вас тоже? Стойте, не убегайте с криками –все не так страшно. Это говорит вам человек, которыйзаменил курс математики в колледже курсом филосо-фии. Делайте, как я: просто посчитайте все на кальку-ляторе и скопируйте результат в CSS. Калькуляторы –просто спасение для таких, как мы, правда?)

Итак, формула у нас есть, давайте вернемся к на-шему заголовку в 24px. Если предположить, что базо-вый кегль (font size) элемента body равен 16 пик-селям при 100 %, мы можем подставить эти значениянепосредственно в формулу. В результате получим от-ношение целевого кегля заголовка h1

(24 пикселя, 24px) и кегля его контекста (16 пиксе-

лей, 16px):24: 16 = 1,5Так как 24 пикселя в 1,5 раза больше 16 пикселей,

это значит, что кегль равен 1,5 em.h1 {font-size: 1.5em; /* 24px / 16px */font-style: italic;font-weight: normal;}Вуаля! Размер нашего заголовка прекрасно совпа-

дает с размером, указанным в оригинал-макете, но приэтом выражен в относительных, масштабируемых еди-ницах (рис. 2.7).

(Обычно я оставляю комментарий с расчетами справой стороны (/* 24px / 16px */). Вносить изме-нения становится намного проще.)

С этим закончили, давайте вернемся к нашей одино-кой маленькой ссылке Read More (узнать больше). Хо-тя, если посмотреть на рис. 2.7, она не такая уж и ма-ленькая. И это проблема. Нам нужно уменьшить задан-ные 11 пикселей, и довольно существенно, посколькуразмер его шрифта принял значение 1,5 em от егоконтекста, h1.

Рис. 2.7. Размер нашего заголовка правильно выражен в гибких, мас-

штабируемых единицах em. (Но что за ерунда творится со ссылкой?)

И вот здесь требуется внимание. Поскольку текст за-головка установлен равным 1,5 em, любые элементывнутри этого заголовка должны быть выражены в ви-де доли этого значения. Другими словами, изменилсянаш контекст.

Поэтому, чтобы установить кегль ссылки в единицахem, мы делим целевые 11 пикселей (11px) не на 16(значение, установленное в body), а на 24 – кегль за-головка, наш новый контекст:11: 24 = 0,458333333333333Мы получили какое-то совсем некрасивое число.

Может быть, самое некрасивое, которые вы сегоднявидели. (Но подождите, эта глава еще не окончена.)

Вам захочется округлить его до более-менее при-емлемого числа – скажем, 0,46 em. Даже не ду-майте! Может, ваши глаза и устанут смотреть на

0,458333333333333, но именно это число идеаль-но представляет желаемый кегль в пропорциональномотношении. К тому же браузеры мастерски владеют ис-кусством округления лишних десятичных знаков, когдапреобразовывают значения в пиксели. Поэтому нужнодать им больше, а не меньше, и в конце вас будет ожи-дать отличный результат.

Теперь просто скопируйте это непритязательное чи-сло в CSS:h1 a {font: bold 0.458333333333333em Calibri,

Optima, Arial, sans-serif; /* 11px / 24px */color:#747474;letter-spacing: 0.15em;text-transform: uppercase;text-decoration: none;}Посмотрим на результат. Наша страничка законче-

на, она полностью соответствует желаемому дизай-ну, а текст задан в масштабируемых единицах em(рис. 2.8).

Рис. 2.8. С помощью простой математики мы создали более красивый

дизайн – и без всяких пикселей

От гибких шрифтов к гибкой сетке

Вы, наверное, сейчас зеваете со скуки. Здесь ведь

должна была быть глава про гибкие макеты, а этот типИтан все талдычит про математику и размеры шриф-тов. Надоело!

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

Когда я понял, как устанавливать размеры текста вединицах em, на меня снизошло прозрение: ведь мыможем применять тот же принцип пропорциональногомышления и в отношении самих макетов. Другими сло-вами, все элементы нашей сетки – строки, колонки инакладываемые на них модули – могут быть выраженыкак пропорция содержащихся в них элементов, а не внеизменных, жестких пикселях.

И в этом нам снова поможет наша формула target÷ context = result. Идем дальше.

Создание гибкой сетки

Представьте, что дизайнер настолько впечатлен ва-

шей быстрой и качественной работой над заголовком,что прислал вам другой макет, и теперь вам нужно на-писать код для блога сайта Robot or Not (рис. 2.9).

Рис. 2.9. Новое задание – превращение эскиза в гибкий макет

Плюс ко всему дизайнеру настолько понравиласьработа, что он прислал краткую схему содержаниястраницы (рис. 2.10), благодаря чему мы можем нетратить время на планирование. Нужно как-то его от-

благодарить.

Рис. 2.10. Схема расположения элементов для нашего блога

Мы можем быстро и ловко перевести его схему в ба-зовую структуру верстки:<div id="page"><div class="blog section"><h1 class="lede">Recently in <a

href="#">The Bot Blog</a></h1><div class="main">…</div><!– /end.main – ><div class="other">…

</div><!– /end.other – ></div><!– /end.blog.section – ></div><!– /end #page – >Наша разметка получилась простой и аккуратной,

семантически верной и превосходно подходит для кон-тента. Мы создали основной контейнер для всей стра-ницы (#page), который, в свою очередь, содержит мо-дуль .blog. Внутрь него мы поместили еще два блока:один с классом .main для главного содержания ста-тьи, а второй с классом .other для всего остально-го. Звучит, конечно, не слишком поэтично, но, с другойстороны, это и не сборник стихов.

А теперь пропустим несколько этапов – как это де-лается на кулинарных шоу, где повар кладет в кастрю-лю сырые продукты, а через минуту вынимает из ду-ховки полностью готовую индейку. (Эта метафора пре-красно демонстрирует то, как часто я смотрю кулинар-ные шоу… или готовлю индейку.)

И все же предположим, что мы уже создали все CSS,связанные со шрифтами, фоновыми изображениями ивсеми элементами нашего дизайна, не имеющими от-ношения к макету (рис. 2.11). Теперь мы можем сосре-доточиться исключительно на создании «резиновой»сетки.

Рис. 2.11. Работа над шаблоном закончена! Если, конечно, не прини-

мать во внимание то, как он должен выглядеть в самом конце

Так как же нам превратить эти блоки .main и.other в нужные колонки? У нас уже есть схема кон-тента и основная разметка, теперь давайте вниматель-нее взглянем на физические параметры сетки в ориги-нальном дизайне (рис. 2.12).

Рис. 2.12. Теперь наша страница основана на сетке!

Сама сетка разделена на 12 колонок по 69 пикселейкаждая, отделенных друг от друга промежутками ши-риной в 12 пикселей (12px). В сумме колонки и проме-жутки дают нам полную ширину в 960px. Сам же блогшириной 900 пикселей отцентрирован по горизонталив пределах холста.

Вот они, детали высокого уровня. И если мы внима-тельно рассмотрим две колонки в блоге (рис. 2.13), тоувидим, что ширина левой основной колонки (.main внашей разметке) составляет 566 пикселей, в то времякак ширина правой вспомогательной (.other) – толь-ко 331 пиксель.

Рис. 2.13. Давайте-ка изучим детали и измерим ширину внутренних

колонок

Что-то слишком много пикселей вокруг, да? И еслибы пиксели нас устраивали, мы могли бы просто пере-нести их в CSS. (Эй! Это очень важно!)#page {margin: 36px auto;width: 960px;}.blog {margin: 0 auto 53px;width: 900px;}.blog.main {float: left;width: 566px;}.blog.other {

float: right;width: 331px;}Отлично. Мы установили ширину #page в 960 пиксе-

лей, отцентрировали в ней модуль .blog шириной 900пикселей, задали ширину.main (566) и.other (331)и наконец-то разместили эти колонки рядом. Результатвыглядит шикарно (рис. 2.14).

Рис. 2.14. Мы избавились от ненужных пикселей, и наш дизайн почти

готов. Или нет?

И хотя наш макет идеально совпадает с ориги-нал-макетом, он получился совсем негибким. Фиксиро-ванная ширина в 960px делает нашу страницу совер-шенно безразличной к изменениям размеров областипросмотра. Иными словами, если ширина окна будетменьше 1024 пикселей, перед читателем появится по-лоса горизонтальной прокрутки (рис. 2.15).

И нас это, мягко говоря, не устраивает.

Рис. 2.15. Дизайн выглядит отлично, но он совсем негибкий. Давайте

это исправим

От пикселей к процентам

Вместо того чтобы переносить значения в пиксе-

лях из оригинал-макета в CSS, мы должны переве-сти эти размеры в относительные, пропорциональныезначения. В результате мы получим сетку, которая бу-дет трансформироваться в зависимости от областипросмотра, причем оригинальные пропорции дизайнаостанутся неизменными.

Давайте начнем с первого элемента #page, которыйсодержит наш макет, и попробуем что-нибудь с нимсделать:#page {margin: 36px auto;width: 960px;}Противные, гадкие пиксели. Терпеть их не можем!Ну ладно, не такие уж они и отвратительные. По-

мните: в макетах с фиксированной шириной нет ниче-го плохого! Но нам нужна более гибкая сетка, поэтомудавайте попробуем перевести эти 960 пикселей в про-центы.#page {margin: 36px auto;width: 90 %;

}Должен признаться, что я пришел к этим 90 % без

особых на то оснований, просто пробовал различныеварианты в окне браузера, а затем выбрал тот, что по-нравился мне больше всего. Задавая значение эле-мента #page в процентах, мы создаем контейнер, ко-торый будет увеличиваться и уменьшаться в зависи-мости от области просмотра (рис. 2.16). И поскольку онотцентрирован по горизонтали, справа и слева оста-нутся отступы по 5 %.

Рис. 2.16. Наш контейнер изменяется в размерах при любом измене-

нии размера окна браузера

Пока все идет неплохо. Теперь давайте примемсянепосредственно за модуль .blog. Чуть ранее, когдамы играли с пикселями, то установили следующее пра-вило:.blog {margin: 0 auto 53px;width: 900px;}Теперь вместо величины в пикселях мы должны вы-

разить ширину элемента .blog в пропорциональныхвеличинах: описать ее как процент ширины содержа-щего его элемента. И вот здесь нам снова пригодитсяформула target ÷ context = result.

Из оригинал-макета мы знаем, что ширина наше-го блога должна составлять 900px. Теперь нам нуж-но представить эту ширину в относительных единицах,процентах ширины родительского элемента для эле-мента .blog. Поскольку блок .blog вложен в элемент#page, ширина которого в соответствии с оригинал-ма-кетом составляет 960 пикселей, это и есть наш кон-текст.

Давайте разделим ширину .blog (900) на его кон-текст (960):900 / 960 = 0,9375У нас получилось 0,9375. Число выглядит не особен-

но впечатляюще. Но, передвинув запятую на два зна-ка, мы получаем 93,75 % и заносим их прямо в CSS:.blog {margin: 0 auto 53px;width: 93,75 %; /* 900px / 960px */}(Так же как и в случае с размерами шрифтов, я за-

писал формулу в поле комментария справа от значе-ния ширины (width). Это, разумеется, дело вкуса, ноя нахожу это очень полезным.)

Итак, с двумя элементами мы разобрались. Но чтоделать с колонками?.blog.main {float: left;width: 566px;}.blog.other {float: right;width: 331px;}Ширина основной колонки, которая расположена

слева, составляет 566px, ширина же левой колонкиравна 331px. Эти цифры нам тоже придется переве-сти в проценты. Но прежде чем подставить их в фор-мулу, обратите внимание на то, что контекст изменил-ся. Последний раз мы делили ширину модуля .blogна 960, ширину его контейнера (#page). Но поскольку

эти блоки вложены в .blog, нам нужно делить целе-вую ширину колонок (566 и 331) на ширину их новогоконтекста, то есть ширину .blog (900). В результатемы получаем:566 / 900 = 0,628888889331 / 900 = 0,367777778Передвинув запятую на два знака, мы получа-

ем в итоге 62,8888889 % для блока .main и36,7777778 % для блока .other:.blog.main {float: left;width: 62.8888889 %; /* 566px / 900px */}.blog.other {float: right;width: 36.7777778 %; /* 331px / 900px */}Вот мы и получили гибкий макет (рис. 2.17). При по-

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

Рис. 2.17. Наша гибкая сетка готова

Гибкие поля и отступы

Теперь, когда две колонки стоят на своих местах,

можно сказать, что мы закончили с основными ком-понентами нашей гибкой сетки. Изумительно. Замеча-тельно. Великолепно. И все же этого недостаточно: насждет работа над деталями.

Не продохнуть…

Наш дизайн уже достаточно гибок, однако он требу-

ет серьезного внимания к двум основным деталям. На-звание блога уехало далеко влево (рис. 2.18), а две ко-лонки примыкают друг к другу без каких-либо отступовили промежутков (рис. 2.19). Определенно, нам нужноеще поработать.

(Конечно, на самом деле мы без них страдаем.)

Рис. 2.18. Наш заголовок отчаянно нуждается в полях

Рис. 2.19. Отступы? Мы не признаем никаких отступов!

Рис. 2.20. Согласно параметрам эскиза, нам нужно задать горизон-

тальное поле в 48 пикселей с левой стороны заголовка

Ну что ж, давайте начнем с заголовка. В оригиналь-ном макете между началом заголовка и левым краемконтейнера есть промежуток в 48 пикселей (рис. 2.20).Мы, конечно, могли бы задать поле (padding-left) в

пикселях или em:.lede {padding: 0.8em 48px;}Это хорошее решение. Но это фиксированное зна-

чение левого поля (padding-left) создаст промежу-ток, который не будет сочетаться со всей «резиновой»сеткой. И когда гибкие колонки будут становиться у́жеили шире, это поле проигнорирует остальные пропор-ции дизайна, и ширина его всегда окажется 48 пиксе-лей (48px), независимо от того, насколько уменьшил-ся или увеличился весь макет.

Так что мы не пойдем этим путем – мы создадим гиб-кий отступ. Пока что мы использовали относитель-ные единицы измерения только в отношении шириныразличных элементов, но мы можем это сделать и сполями и отступами. И воспользуемся для этого нашейпроверенной формулой:target ÷ context = resultПрежде чем мы снова займемся вычислениями, хо-

чу обратить ваше внимание на то, что контексты длягибких полей и для гибких отступов немного отличают-ся.

1. Задавая гибкие отступы для элемента, прини-майте за контекст ширину контейнера элемента.

2. Задавая гибкое поле для элемента, принимай-те за контекст ширину самого элемента. Подумай-

те о «боксовой» модели, и эти предложения обретутсмысл: мы описываем поле в отношении к ширине са-мого элемента.

Поскольку мы хотим определить поле заголовка, вкачестве контекста мы возьмем ширину самого эле-мента .lede. Ширина заголовка нам неизвестна, по-этому мы берем ширину модуля блога, то есть 900 пик-селей. Снова открываем калькулятор и получаем:48 / 900 = 0,0533333333и переводим результат в:.lede {padding: 0.8em 5.33333333 %; /* 48px /

900px */}Наши 48 пикселей поля теперь выражены в относи-

тельных единицах измерения, как доля ширины заго-ловка.

С этим расправились, идем дальше. Давайте вве-дем понятие пробела в наш контент. Но сначала вспо-мним, что каждая колонка фактически содержит мень-ший модуль: левая колонка .blog содержит модуль.article, а правая .other – список .recent-entries(рис. 2.21).

Рис. 2.21. Взглянув на колонки, мы можем достаточно быстро опре-

делить их ширину

Начнем с последнего. К счастью для нас, тут и де-лать нечего. Мы знаем ширину элемента (231px) и ши-рину содержащей ее колонки (331px), поэтому можемпросто отцентрировать модуль по горизонтали:.recent-entries {margin: 0 auto;width: 69.7885196 %; /* 231px / 331px */}Со статьей (модуль .article) мы можем поступить

так же. Но давайте-ка попробуем кое-что другое.Помните поле шириной 48px, которое мы задали в

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

нальный промежуток.

Рис. 2.22. У заголовка и статьи одинаковые поля

Целевое значение – 48px. А поскольку мы работа-ем с относительным полем, в качестве контекста бе-рем ширину самой статьи. Но, опять же, мы не знаемточной ширины модуля .article, поэтому использу-ем ширину блока .blog, то есть 566px:.article {padding: 40px 8.48056537 %; /* 48px /

566px */}Вуаля! Гибкая сетка закончена (рис. 2.23).

Рис. 2.23. Гибкие поля и отступы! Ура!

Немного отрицательных значений

Давайте обратим внимание на заголовок даты запи-

си в блоге.Пока он занимает всю ширину записи, а так быть

не должно. К этому времени мы уже много чему на-учились, поэтому особых затруднений не возникнет. Напервоначальном дизайне мы видим, что дата распо-ложена слева и занимает одну колонку шириной 69px(вернемся к рис. 2.12). А поскольку дата входит в блокстатьи шириной 474px, мы уже знаем и контекст.

Вооружившись этой информацией, напишем не-большой CSS:.date {float: left;width: 14.556962 %; /* 69px / 474px */}Пока все хорошо и гибко. Но мы упустили один клю-

чевой элемент: на данный момент дата расположенавплотную к левому краю статьи и окружена заголовкоми текстом (рис. 2.24). А нам нужно вынести ее за пре-делы контейнера к левому краю целого модуля.

Рис. 2.24. Прогнило что-то в датском королевстве. (Под «датским ко-

ролевством» я имею в виду дату записи, а когда я говорю «прогнило», то

это значит, что она находится слишком близко к тексту.)

Мы сможем сделать это при помощи отрицательныхотступов, причем нам даже не придется менять прин-цип действий. Как и прежде, все, что нам нужно, – этоопределить ширину отступа по отношению к ширинеконтейнера элемента.

На первоначальном дизайне расстояние от левого

края даты до левого края статьи составляет 81 пиксель(рис. 2.25). Если бы это был дизайн с фиксированнойшириной, эта величина стала бы нашим отрицатель-ным отступом:.date {float: left;margin-left: -81px;width: 69 px;}

Рис. 2.25. Необходимо сдвинуть дату влево на 81px (или соответству-

ющий относительный эквивалент)

Но мы ведь пока еще ни разу не использовали пиксе-ли, так давайте не будем и начинать. И хотя отступ дол-жен быть отрицательным, это не меняет нашу форму-лу. Мы все еще хотим выразить целевое значение, тоесть отступ шириной в 81px, как процентное отноше-ние от ширины содержащего дату элемента в 474px.Переставьте запятую, поставьте минус перед числом –и вы получите пропорциональное отрицательное поле:81 ÷ 474 =.170886076А теперь откиньтесь на спинку кресла, расслабьтесь

и целиком насладитесь моментом: вы впервые созда-ли полностью гибкую сетку (рис. 2.26). Мне хочется по-жать вам руку.

Рис. 2.26. Наша гибкая сетка готова. В основе ее вовсе не пиксели, и

при этом – никаких компромиссов с эстетической точки зрения

Гибко двигаемся дальше

Я понимаю, что из-за меня вам пришлось занимать-

ся расчетами больше, чем хотелось бы. Я сам всегоэтого на дух не переношу и потому – поверьте! – ис-кренне вам сочувствую.

Но создание гибкой сетки – это не только математи-ка. Конечно, формула target ÷ context = resultпомогает превратить размеры в процентные отноше-ния, но вообще-то мы должны сломать нашу привычкупереносить пиксели из Photoshop напрямую в CSS исосредоточить наше внимание на пропорциях, задан-ных в дизайне. Мы должны научиться лучше видетьконтекст, в первую очередь пропорциональное отно-шение между элементом и контейнером.

«Резиновая» сетка – это всего лишь основа, первыйслой отзывчивого дизайна. Давайте двигаться дальше.

3. Гибкие изображения

Ну что ж, ПОКА ДЕЛА идут неплохо. У нас есть гото-

вая сетка, сложностью которой мы в угоду гибкости непожертвовали. Должен признаться: когда я в первыйраз создал гибкую сетку, я невероятно гордился собой.

Но потом, как это часто случается с веб-дизайнера-ми, на меня накатило отчаяние. На нашей страницепрекрасно смотрятся слова, сам текст без усилий под-страивается под гибкий контейнер. Но и все! Я не знаю,заметили ли вы, но в Интернете встречаются еще икартинки. А в нашей гибкой сетке их пока нет.

Что же произойдет, если мы вставим изображение сфиксированной шириной в гибкий дизайн?

Назад к разметке

Чтобы ответить на этот вопрос, давайте проведем

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

Помните тот маленький блок для цитатыblockquote, так удобно вписавшийся в нашу статью?У нас и так уже слишком много текста, давайте заме-ним его на изображение:<div class="figure"><p><img src="robot.jpg" alt="" /><b class="figcaption">Lo, the robot

walks</b></p></div>Ничего особенного: элемент img, за которым следу-

ет короткая, но информативная надпись, заключеннаяв элемент b. Фактически в этом отрезке я использовалтеги figure/figcaption из HTML5 в качестве назва-ний классов, что способствует созданию крепкой се-мантической основы.

(Внимательные читатели могут заметить, что я ис-пользовал элемент b, а это несемантический прием.

Некоторые дизайнеры в этом случае используют тек-стовый элемент span. Что касается меня, то в несе-мантической разметке мне импонирует лаконичностьтаких коротких тегов, как b и i.)

С HTML закончили, давайте перейдем к CSS:.figure {float: right;margin-bottom: 0.5em;margin-left: 2.53164557 %; /* 12px / 474px

*/width: 48.7341772 %; /* 231px / 474px */}У нас получилось прекрасное удобное местечко для

картинки. Она будет располагаться справа и заниматьполовину ширины статьи, или четыре колонки гибкойсетки. Разметку и стиль проверили. Понятное дело, чтовсе эти HTML и CSS не нужны, если нет никакой ре-альной картинки под рукой.

Поскольку я очень хорошо к вам отношусь (почти также, как к роботам), я потратил некоторое время в Се-ти, выбирая подходящую картинку, и нашел фантасти-ческого робота (рис. 3.1). Преимущество этого изобра-жения, помимо самого робота, конечно, еще и в том,что оно просто огромное. Я его немного обрезал, но неуменьшал, а оставил первоначальное разрешение 655х 655. Он явно намного больше, чем гибкий контейнер,который будет его содержать. А значит, у нас есть пре-

красная возможность посмотреть, как будет вести себянаш гибкий макет.

Загружаем эту огромную картинку на сервер, обно-вляем страницу – и что мы видим? Отвратительно. Ху-же не придумаешь (рис. 3.2).

Рис. 3.1. Вполне подходящее изображение робота, использованное с

любезного согласия Джереми Ноубла

Рис. 3.2. Огромное изображение – огромные проблемы

Вообще-то удивляться тут нечему. Макет в принципев порядке – гибкий контейнер работает как надо, а про-порции колонок остались неизменными. Но из-за того,что изображение шире, чем модуль. figure, то, что непоместилось, попросту вылезло за его пределы. Мы не

применили к изображению никаких ограничений, кото-рые бы сочетали его с гибким окружением.

Гибкие изображения

А что если ввести такое ограничение: написать пра-

вило, которое не позволит картинкам выходить за ши-рину их контейнера?

У меня для вас хорошие новости: сделать это прощепростого:img {max-width: 100 %;}Правило, открытое дизайнером Ричардом Раттером

(http://bkaprt.com/rwd/11/), накладывает на любое изо-бражение в документе одно невероятно удобное огра-ничение. Теперь ширина элемента img может быть ка-кой угодно, при условии, что она не превышает шири-ну содержащего его контейнера. В противном случаесвойство max-width: 100 % заставит изображениеограничиться шириной контейнера. И как вы видите,наша картинка прекрасно стала на место (рис. 3.3).

Рис. 3.3. За счет добавления max-width: 100 % мы смогли удержать

наше изображение в рамках контейнера. Вот за что я люблю max-width:

100 %

Рис. 3.4. Вне зависимости от изменения размеров гибкого контейнера

изображение остается пропорциональным. Волшебство? Кто знает…

Более того, современные браузеры умеют пропор-ционально менять размеры картинок. Если гибкий кон-тейнер будет менять свои размеры, уменьшая или уве-личивая изображение, соотношение сторон картинкиостанется неизменным (рис. 3.4).

Я надеюсь, вы еще не устали от хороших новостей,поскольку, как оказалось, правило max-width: 100 %можно применять к большинству элементов с фикси-рованной шириной, таким как видео– и другие медиа-файлы. Фактически мы можем добавить в селектореще и другие медиаэлементы:img,embed,object,

video {max-width: 100 %;}Это может быть небольшое флеш-видео (рис. 3.5),

встроенный медиафайл или скромное изображение –браузеры все сделают сами и поменяют размеры со-ответственно макету. И все благодаря этому чудесно-му ограничению max-width.

Так что же получается, мы действительно решилипроблему гибких изображений? Одно правило – и всеготово?

Рис. 3.5. С параметром max-width: 100 % гибкими становятся и другие

элементы медиа. Я уже говорил, что люблю max-width: 100 %?

Если бы все было так просто…

Теперь займемся неприятными вещами и поговорим

о некоторых особенностях браузеров по отношению кгибким изображениям.

Max-width в Internet Explorer

Суровая правда заключается в том, что Internet

Explorer 6 и ниже не поддерживают свойство max-width. Что касается IE7 и выше, тут все в порядке. Ноесли вы, к моему глубочайшему сожалению, застрялив достопочтенном IE6 или более старой версии брау-зера, то придется кое-что доработать.

Существует несколько путей заставить свойствоmax-width работать в IE6. Большинство из них осно-вано на JavaScript, обычно на базе проприетарногофильтра expression компании Microsoft, для динами-ческой оценки ширины элемента и ручного измененияразмеров в случае превышения установленного лими-та. В качестве примера такого нестандартного подходая могу порекомендовать статью Свенда Тофте (http://bkaprt.com/rwd/12/).

Что касается меня, я все-таки предпочитаю болеепростой CSS-подход. Все современные браузеры под-держивают свойство max-width:img,embed,object,video {max-width: 100 %;

}Но в отдельной таблице стилей для IE6 я бы сделал

так:img,embed,object,video {width: 100 %;}Заметили разницу? В IE6 и ниже правило width:

100 % оказывается важнее max-width: 100 %.Вот здесь внимание: это совершенно разные прави-

ла. Если max-width: 100 % запрещает изображениюпревышать ширину контейнера, то width: 100 % де-лает его ширину равнозначной ширине содержащегоего элемента.

В большинстве случаев этот прием работает от-лично. Например, наша чрезмерно большая картинкаrobot.jpg будет всегда больше содержащего ее кон-тейнера, поэтому правило width: 100 % в этом слу-чае можно применять смело.

Что касается более мелких изображений, напримерминиатюр или большинства встроенных роликов, ихне всегда можно слепо масштабировать при помощиCSS. В этом случае для IE лучше сделать так:img.full,object.full,

.main img,

.main object {width: 100 %;}Если вы не хотите на вашей странице применять

правило width: 100 % ко всем медиафайлам с фик-сированной шириной, то можете написать список се-лекторов, которые будут размечать определенные ви-ды изображений или видео (img.full) или опреде-ленные области документа, в которые вы будете вста-влять файлы большого размера (.main img, mainobject). Если изображения или другие медиафайлыпоявятся в этом списке, они станут гибкими, в против-ном случае – останутся в своем отсталом пиксельномсостоянии.

Таким образом, если вы все еще работаете с мо-рально устаревшими версиями Internet Explorer, вни-мательно применяйте это правило, и все получится.Эту проблему мы решили, переходим к следующей.

И это что-то.

…И здесь становится понятно,

что Windows нас ненавидит

Если вы посмотрите на модуль блога в каком-нибудьбраузере на базе Windows, наша картинка robot.jpgпревратится из впечатляющей в нечто непонятное(рис. 3.6).

Рис. 3.6. При просмотре в IE6 можно заметить, что наше изображение

робота содержит некоторые нежелательные артефакты. Судя по всему,

Windows не особенно пригоден для гибких изображений

И это проблема не браузера, а платформы: Windowsне очень правильно определяет масштаб изображе-ний. В Windows изображения, размеры которых изме-

нены средствами CSS, быстро «обрастают» различны-ми артефактами, что крайне плохо сказывается на ихкачестве.

Для проверки я забросил картинку с текстом в гибкийконтейнер и изменил размер изображения при помощиправила max-width: 100 % во всех браузерах, а в IE6и ниже при помощи width: 100 %. Ясное дело, чтоникто не поместит такой объем текста в изображение,но этот пример прекрасно демонстрирует то, насколь-ко все плохо с картинками в IE7 и более старых верси-ях. Как видите, картинка выглядит просто тошнотвор-но, прошу прощения за мой французский (рис. 3.7).

Рис. 3.7. В некоторых браузерах для Windows изображение «обраста-

ет» большим количеством артефактов, что реально мешает восприятию

Но прежде чем опускать руки, обратите внимание нато, что этот баг появляется не во всех браузерах на ба-зе Windows. На самом деле от этой проблемы страда-ют только Internet Explorer 7 и ниже и Firefox 2 и ниже.

Более современные браузеры, такие как Safari, Firefox3+ и IE8+, не возражают против гибких изображений.Плюс ко всему в Windows 7, кажется, починили этотбаг, – еще одна хорошая новость.

Может быть, теперь, когда мы выяснили, в чем про-блема, мы сможем использовать какой-нибудь патч?Да, сможем (правда, за исключением Firefox 2).

Эта почтенная старая версия выпущена в 2006 го-ду, поэтому я не думаю, что ею пользуется сколько-ни-будь значительное число посетителей вашего сайта.Так или иначе, патч для Firefox 2 потребует анали-за браузера для выявления определенных версий наопределенной платформе, а такой анализ, мягко гово-ря, ненадежен. Но даже если мы решим его выполнить,в старых версиях Firefox нет возможности исправитьтакие изображения.

В Internet Explorer же такая возможность есть. (При-дется поступиться своим самолюбием ради названияследующего раздела.)

Да здравствует герой-

победитель AlphaImageLoader!

Вы когда-нибудь пытались сделать изображения вформате PNG прозрачными в IE6 и ниже? Если да,то вы наверняка использовали AlphaImageLoader,проприетарный CSS-фильтр компании Microsoft (http://bkaprt.com/rwd/13/). Чтобы обеспечить поддержку PNGс альфа-каналом в IE, создано достаточно много пат-чей (библиотека Дрю Диллера DD_belatedPNG – моясамая любимая: http://bkaprt.com/rwd/14/), но так ужисторически сложилось, что, когда нужно прикрепитьPNG к фону элемента, в таблицу стилей для IE нужнонаписать следующее правило:.logo {background: none;filter: progid:

DXImageTransform.Microsoft.AlphaImageLoader(src="/path/to/logo.png", sizingMethod="scale");}Этот патч делает несколько вещей. Сначала он

удаляет фоновое изображение из элемента, затемвставляет его в объект AlphaImageLoader, кото-рый расположен между настоящим фоновым сло-ем и контентом элемента. Однако умное свойство

sizingMethod (http://bkaprt.com/rwd/15/), которое гово-рит объекту AlphaImageLoader, что ему нужно обре-зать (crop) какие-либо части изображения, вылезаю-щие за контейнер, видит в нем обычное изображение(image) либо адаптирует его размер (scale) под содер-жащий его элемент.

Я так и вижу, как вы пытаетесь подавить зевок: в кон-це концов, какое отношение PNG-патчинг в IE имеет кнашим испорченным картинкам?

Как оказалось, самое непосредственное. В какой-томомент я обнаружил, что, если к изображению приме-нить AlphaImageLoader, это существенно улучшаеткачество его отображения в IE, что ставит этот бра-узер на одну ступеньку с любым другим браузером.Кроме того, задав свойство sizingMethod для мас-штабирования (scale), мы сможем использовать объ-ект AlphaImageLoader для создания иллюзии гибко-го изображения.

Я сварганил небольшой JavaScript, чтобы автомати-зировать этот процесс. Просто скачайте скрипт (http://bkaprt.com/rwd/16/) и вставьте его в любую страницус гибкими изображениями; он подготовит ваш доку-мент для создания гибких, высококачественных объек-тов AlphaImageLoader.

Разницу можно заметить невооруженным глазом(рис. 3.8) – из почти полностью искаженного наше изо-бражение превратилось в безупречное. То же можно

сделать и с гибким контекстом.

Рис. 3.8. Теперь наше изображение отлично читается и великолепно

масштабируется. Скажем же спасибо AlphaImageLoader!

(Стоит упомянуть тот факт, что проприетарныефильтры Microsoft, и в частности AlphaImageLoader,снижают производительность – более подробно всеподводные камни этого метода описывает Стоян Сте-фанов в блоге YUI (http://bkaprt.com/rwd/17/). Поэтомутщательно протестируйте это правило, проверьте ре-зультаты на своих пользователях и решите для себя,стоит ли улучшенное отображение таких издержек.)

При применении правила max-width: 100 %(а также правила width: 100 % и патчаAlphaImageLoader) вложенные картинки прекрасноменяют свой размер наряду со всей гибкой сеткой во

всех браузерах в зависимости от размера окна брау-зера.

Но что делать с изображениями, которые отсутству-ют в нашей верстке?

Гибкие повторяющиесяфоновые изображения

Представим, что наш уважаемый дизайнер прислал

исправленный макет модуля блога. Заметили, что из-менилось (рис. 3.9)?

Рис. 3.9. Теперь у нас появилась фоновая графика. Это круто!

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

Рис. 3.10. Детальный взгляд на новый фон

Но как нам добавить этот новый фон к уже существу-ющему шаблону?

Еще в 2004 году Дэн Седерхольм написал прекрас-ную статью о том, как использовать вертикально по-вторяющуюся фоновую графику для создания эффек-та «фальшивой колонки» (http://bkaprt.com/rwd/18/). Ге-ниальность технологии в ее простоте: повторяя цвет-ное фоновое изображение по вертикали позади наше-го контента, мы создаем иллюзию колонок одной вы-соты.

В оригинальной версии Дэна фоновая графика рас-

полагалась по центру вверху области с контентом и по-вторялась по вертикали:.blog {background: #F8F5F2 url("blog-bg.png")

repeat-y 50 % 0;}И этот прием работал великолепно. Однако он был

рассчитан на макет с фиксированной шириной, то естьсоздавал графику, которая совпадала с ним по шири-не. Как же, интересно, мы будем работать с фоновымизображением, которое покрывает две гибкие колон-ки?

Благодаря некоторым исследованиям дизайнераДага Баумана (http://bkaprt.com/rwd/19/) мы все ещеможем применять технологию «фальшивой колонки».Просто нужно уделить немного больше внимания пла-нированию и вытащить на свет нашу любимую форму-лу target ÷ context = result.

Сперва нужно снова глянуть на наш первоначаль-ный макет, чтобы найти точку перехода на фоновойграфике, точный пиксель, на котором белая колонкапереходит в серую. Судя по всему, это происходит на568 пикселе (рис. 3.11).

Рис. 3.11. Белая колонка переходит в серую на отметке 568px. Это и

есть наша точка перехода

Вооружившись этой информацией, мы можем ада-птировать подход «фальшивой колонки» к нашей «ре-зиновой» сетке. Сначала нам нужно конвертироватьточку перехода в процентное значение, соответствую-щее ширине модуля нашего блога. Чтобы это сделать,снова воспользуемся формулой target ÷ context= result. Целевое значение – 568px, ширина макета(контекста) – 900px. Подставляем эти цифры в фор-мулу:568 ÷ 900 = 0.631111111111111И снова получаем какое-то невероятно длин-

ное число, которое превращаем в проценты –63,1111111111111 %

Запомните его. Затем откройте ваш любимый редак-тор изображений и создайте какой-нибудь огромныйдокумент, шириной, скажем, 3000 пикселей (рис. 3.12).А поскольку мы собираемся повторять его по вертика-ли, высоту сделайте 160px.

Рис. 3.12. Невероятно большой холст, который мы совсем скоро пре-

вратим в фоновую графику

Именно из этого документа мы сделаем нашу фоно-вую графику. Вы можете спросить: зачем такой боль-шой? Я отвечу: изображение должно быть больше, чемлюбое окно браузера. Полагаю, что, если только вы нечитаете этот текст из XXV века с какого-нибудь экранашириной на всю стену, сделанного из голограмм иличего-то не менее мудреного, ваш монитор не будет ши-ре этого изображения.

Чтобы сделать сами колонки, нам нужноприменить процентное значение точки перехода(63,1111111111111 %) к новому широкому холсту. Тоесть, если ширина графики 3000 пикселей, мы перем-ножаем эти два числа:3000 x 0.631111111111111 =

1893.333333333333и в результате получаем 1893,333333333333. А

поскольку Photoshop не хочет иметь дело с десятичны-ми долями, давайте округлим это число до 1893 пик-селей. Нам осталось только создать нашу текстуру из

нового файла, сделав переход от белого цвета к серо-му на 1893-м пикселе (рис. 3.13).

Рис. 3.13. Мы применили к широкому фоновому изображению про-

центы, что привело к созданию колонок

Что это нам дает? Только что мы пропорциональноопределили точку перехода на новом широком холсте.При помощи нового пиксельного значения мы можемсделать нужные нам колонки: белая будет шириной в1893px, а серая займет всю остальную часть изобра-жения.

Осталось сделать одно: вписать новую графику в та-блицу стилей:.blog {background: #F8F5F2 url("blog-bg.png")

repeat-y63.1111111111111 % 0; /* 568px /900px */}Следуя оригинальной технологии Дэна, мы распола-

гаем графику в самом верху нашего блога и повторя-

ем ее по вертикали (repeat-y). Благодаря постоянно-му повторению процентного значения точки перехода(63,1111111111111 % 0) колонки остаются неизмен-ными по отношению друг к другу, независимо от того,какого размера становится сам макет.

В результате мы получили прекрасные фальшивыеколонки в «резиновом» макете (рис. 3.14). Все благо-даря оригинальному подходу Дэна Седерхольма, при-правленному небольшими пропорциональными раз-мышлениями.

Рис. 3.14. Идеально гибкие колонки

Полностью гибкие

фоновые изображения?

Конечно, наши гибкие фальшивые колонки, вооб-ще-то, совсем не гибкие: мы просто использовали про-центное значение в размещении фонового изображе-ния так, чтобы колонки меняли свои размеры в зависи-мости от размеров контейнера. Размеры изображенияпри этом остаются неизменными.

Но что делать, если нам нужно, чтобы фоновое изо-бражение тоже меняло свои размеры вместе с маке-том? Например, вы разместили логотип на фоне эле-мента h1 или используете спрайты2 для создания рол-ловер-эффекта в навигации сайта. Сможем ли мы из-менить размеры картинок, изображенных на фоне?

Сможем. Существует CSS3-свойство под названи-ем background-size (http://bkaprt.com/rwd/20/), кото-рое позволяет создать действительно гибкие фоновыеизображения, однако, как вы, наверное, уже догада-лись, не все браузеры обеспечивают его поддержку.

Но существует несколько отличных решений на базеJavaScript: например, jQuery-плагин Backstretch Скот-та Робина (http://bkaprt.com/rwd/21/), который позволя-

2 Графические объекты в компьютерной графике чаще всего растровыеизображения, свободно перемещающиеся по экрану.

ет добавлять масштабируемые фоновые изображе-ния для элемента body. Как вы узнаете из следующейглавы, медиазапросы CSS3 также можно использо-вать для адаптации различных фоновых изображенийк различным диапазонам разрешений. Так что если нетвозможности использовать background-size, впол-не возможно найти другое решение. Для пытливогоума нет преград – гласит народная мудрость.

Как научиться любить Overflow

Существует еще несколько способов адаптации изо-

бражений с фиксированной шириной к «резиновому»контексту. Посмотрите эксперименты Ричарда Ратте-ра с широкими изображениями в гибких макетах (http://bkaprt.com/rwd/11/). Раз уж вы решили заняться отзыв-чивым дизайном, изучите эти способы, некоторые изних могут оказаться весьма полезными.

Лично я несколько раз использовал свойствоoverflow. Как мы узнали из предыдущей главы, широ-кие изображения могут попросту вылезать за пределысвоих контейнеров. И в большинстве случаев для ихограничения лучше всего использовать правило max-width: 100 %. Но можно и обрезать эти лишние дан-ные, применив свойство overflow: hidden. То естьвместо того, чтобы позволить изображению изменитьсвои размеры автоматически:.feature img {max-width: 100 %;}мы можем попросту отрезать лишние данные:.feature {overflow: hidden;}

.feature img {display: block;max-width: auto;}В результате получаем изображение, обрезанное

под свой контейнер (рис. 3.15). Оно никуда не делось,просто его лишние элементы не видны.

Однако это не лучшее решение. На самом деле ясчитаю, что в большинстве случаев overflow про-игрывает max-width. Но этот метод имеет право на су-ществование и в некоторых случаях даже может бытьполезным.

Рис. 3.15. Применив overflow: hidden к контейнеру нашего изображе-

ния, мы получили обрезанное изображение. Можно крикнуть «ура»

Проблемы с контентом

В большинстве случаев и свойство overflow, и пра-

вило max-width: 100 % довольно функциональныи работают для большинства медиа-файлов. Лично яуспешно применял их в различных «резиновых» сет-ках.

Но при этом оба подхода абсолютно нечувствитель-ны к содержанию. Каждый из них устанавливает неко-торые основные правила, которым следуют изображе-ния по отношению к своим контейнерам: max-width:100 % масштабирует картинку в соответствии с разме-рами контейнера, а overflow позволяет убрать лиш-ние данные, выходящие за его пределы.

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

Рис. 3.16. Эта отличная инфографика с сайта BBC News содержит

жизненно необходимую с точки зрения контента информацию. Простое

масштабирование может оказаться неэффективным

В этом случае нужно найти способы передачи раз-личных вариантов одной и той же картинки в разныхдиапазонах разрешений. Другими словами, вы може-те создать один образец для десктопных браузеров, авторой, более линейный, – для устройств с маленьки-ми экранами. Задав эти параметры, вы можете поло-житься на сервер, который сам выберет наиболее под-ходящее изображение.

Такое решение выходит за рамки данной книги (и невсегда по силам вашему покорному слуге), однако ди-зайнер-разработчик Брайан Ригер описал возможныйподход в своем блоге (http://bkaprt.com/rwd/23/), откудавы и сможете его скачать.

Если вы решили использовать серверное решение,его можно укрепить различными клиентскими приема-ми, которые мы уже обсуждали. Например, вы можетесоздать несколько вариантов изображения под разныедиапазоны разрешений, а затем использовать правилоmax-width: 100 %, чтобы сгладить переход на дру-гие устройства, браузеры и диапазоны разрешений.

Гибкие сетки и изображения

как древо познания

Итак, к этому моменту мы изучили все, что необхо-димо для успешного создания сложных, но гибких ма-кетов: простая математика для гибких сеток и немно-го стратегических решений для изображений и другихмедиафайлов. Все эти знания вы можете применять нетолько по отношению к блогу, который мы писали, нои ко всему сайту Robot or Not, создавая дизайн, осно-ванный на системе пропорций и процентов, без всякихпикселей (рис. 3.17).

Имея на руках гибкую основу, мы готовы добавитьеще один ингредиент к нашему отзывчивому дизайну.

Рис. 3.17. Использовав рекомендации, содержащиеся в двух главах,

мы получили завершенный и гибкий макет, который может расширяться

и сужаться в зависимости от размеров окна браузера

4. Медиазапросы

В общем-то, я всегда был противником фиксирован-

ной верстки. Я с самого начала чувствовал, что буду-щее – за макетами, которые обладают гибкостью хоть вмалейшей степени, ведь они всегда могут подстроить-ся под размеры окна, экрана или разрешения устрой-ства. Более того, настаивая на необходимости гибко-сти, я часто использовал эпитеты «перспективный» и«приспосабливающийся». Увы, ко мне не очень-то при-слушивались и считали страшным занудой.

Но в какой-то момент все изменилось.Однако вернемся к нашему сайту Robot or Not. Мы

сделали его максимально гибким, однако он все жееще не очень надежный. Да, «резиновая» сетка сде-лала его менее чувствительным к изменениям разме-ра окна или разрешения экрана, чем при фиксирован-ном макете. Однако изменения в размере и форме ок-на браузера могут вызвать деформацию всей верстки.

И знаете что? В этом нет ничего страшного!

Приступим к лечению

Понимаю, это неприятно, но все же нам придется по-

нять, что именно случилось с нашим дизайном и гдеон нарушился. Определив все проблемы, мы сможемэффективно их устранить, даже если придется немно-го помучиться в процессе.

Поскольку мы работаем с гибким макетом, мы мо-жем просто изменить размеры окна браузера. Это, ко-нечно, не заменит полноценного тестирования на от-дельных устройствах, но позволит быстро оценить, каксебя поведет наш дизайн в различных диапазонах раз-решений. Мы увидим, как именно он будет выглядетьна экране телефона, планшета или другого устройства.

Расстановка акцентов

Прежде всего, изменим разрешение окна браузера

с 1024 пикселей на 760 пикселей (рис. 4.1). Проблемысразу же станут весьма наглядными.

Рис. 4.1. Чтобы понять, каким образом будет выглядеть наш дизайн

при разном разрешении экрана, достаточно изменить размеры окна бра-

узера

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

лось, но – с визуальной точки зрения – стало каким-тоневзрачным.

Обратите внимание на то, что картинка в верхнейчасти сайта стала занимать практически всю страни-цу (рис. 4.2). Поскольку мы обрезали ее при помощисвойства overflow, она не адаптировалась под измене-ния всей сетки. Кроме того, само изображение – нашлюбимый робот – теперь обрезано. То есть картинка нетолько огромная, но и непонятная. Кошмар какой-то…

Рис. 4.2. В верхней части нашего дизайна творится что-то не то

На фоне этой гигантской картинки логотип выглядитсовсем крошечным, а поле между навигацией и картин-кой исчезло. Глядя на все это, испытываешь приступ

клаустрофобии.Мне неприятно это говорить, но даже при неболь-

шом уменьшении разрешения сайт превращается внелепое нагромождение различных элементов.

Маленькая сетка,

большие проблемы

И это еще не самое ужасное. Если мы уменьшим ок-но браузера до 600 пикселей – ширины окна малень-кого браузера или портретного режима на планшет-ном компьютере, – наша головная боль только усилит-ся (рис. 4.3). В верхней части экрана творится полноебезобразие: картинка обрезана настолько, что непо-нятно, что там вообще изображено, а бедный логотипстал еще меньше. Навигация же выглядит просто не-потребно. С этим нужно срочно что-то делать.

Рис. 4.3. Любой посетитель сайта будет в восторге от нашего исковер-

канного дизайна (это сарказм)

Двигаемся ниже. Господи, что же это происходитс сайтом (рис. 4.4)! Раньше двухколоночная версткаобеспечивала легкий доступ к дополнительной инфор-мации, сейчас же она сжимает текст, такие короткиестрочки читать крайне неудобно. Фотография не со-впадает с текстом, а что на ней изображено, не понятьникому.

Рис. 4.4. Эта запись напоминает японское стихотворение хайку –

строчки, короткие до боли

И наконец, заканчивая наш печальный обзор, по-смотрим на фотографии в нижней части страницы. Онивыглядят хуже всего (рис. 4.5), даже хуже картинки вверхней части. Они такие маленькие, что разглядеть,что там на них, невозможно.

Широкие поля, которые мы использовали для обра-мления этих картинок, превратились в огромные про-бельные моря, поглотившие их.

Рис. 4.5. Мелкие картинки, монструозные поля. Отвратительно!

Широкоэкранные неприятности

Однако проблемы возникают не только тогда, ко-

гда разрешение экрана меньше. Если мы максимальноувеличим окно браузера, на свет вылезут новые про-блемы. Верхняя часть страницы выглядит довольнонеплохо (рис. 4.6), правда, картинка теперь меньше,чем выделенное под нее место. В остальном же всеболее-менее нормально… Ну, далеко от идеального,но вытерпеть можно. Сетка в целом сохранилась хоро-шо.

Рис. 4.6. Верхняя часть выглядит довольно широкой

А теперь прокрутим страницу вниз, и наше радост-ное настроение вмиг испарится (рис. 4.7). Помните, ка-кими короткими выглядели строчки текста в маленькомокне? Глядя на то, что появилось на экране, я начи-наю по ним скучать. Теперь строчки стали невероятнодлинными, и, несмотря на то, что ничто не доставляетмне большего удовольствия, чем выискивать следую-щую строчку после прочтения предыдущей, придетсяискать другой способ.

Рис. 4.7. Двигаясь вниз по странице, мы видим все больше проблем.

Длинные строки, крошечные изображения, печальный Итан

Ко всему прочему, фотографии в нижней части стра-ницы стали невероятно большими (рис. 4.8). Выглядят

они неплохо, но занимают слишком много места. Насамом деле на моем мониторе даже и не видно, естьли что-то над или под этим блоком. Интересно, можеммы сделать хоть что-то, чтобы читатели не сломалиглаза, рассматривая наш сайт?

Рис. 4.8. Говоря техническим языком, эти изображения слишком круп-

ные и массивные

Насущные проблемы

Итак, мы определили основные визуальные непо-

ладки. Однако нужно смотреть на проблему шире. Кактолько мы меняем оригинальное разрешение, сеткаоказывает нежелательное воздействие на контент. Еепропорции ограничивают содержание при низких раз-решениях и окружают его пустым пространством – привысоких.

Причем эта проблема возникает не только с гибки-ми макетами. Ни один дизайн, фиксированный или гиб-кий, не сможет масштабироваться вне контекста, длякоторого он спроектирован.

Так как же нам сделать дизайн, который будет ада-птироваться к изменениям разрешения экрана и раз-меров области просмотра? Как сделать так, чтобыстраница оптимизировалась в соответствии с браузе-ром и устройством, на котором ее просматривают?

Другими словами, как сделать наш дизайн более от-зывчивым?

Навстречу отзывчивости

К счастью, Консорциум Всемирной паутины (World

Wide Web Consortium, W3C) уже некоторое время за-нимается этой проблемой. Но чтобы лучше понятьрешение, которое в результате было представлено,обратимся к предыстории.

Знакомьтесь: медиатипы

Первым шагом в решении проблемы стали медиа-

типы (media types), часть спецификации CSS2 (http://bkaprt.com/rwd/24/). Вот как они первоначально описы-вались:

Иногда таблицы стилей для различныхмедиатипов могут иметь одинаковое свойство,но требовать разных значений для этогосвойства. Например, свойство font-size можноиспользовать как для монитора, так идля вывода документа на печать. Эти двамедиатипа отличаются друг от друга итребуют разных значений для одного и тогоже свойства; документ обычно имеет большийшрифт на мониторе, чем на бумаге. Поэтомуэто нужно отобразить в таблице стилей или вразделе таблицы, применяемой к определенныммедиатипам.

Ничего не понятно, да? Давайте попробуем разо-браться без нагромождения терминов.

Вы писали когда-нибудь стили для печати (http://bkaprt.com/rwd/25/)? Тогда вы, наверное, знакомы с по-нятием разработки для различных видов медиа. Дажеидеальное браузерное отображение не делает ника-кой разницы между десктопными браузерами и прин-

терами или между мобильными устройствами и голо-совым браузером. Чтобы решить эту проблему, W3Cсоздала список медиатипов (http://bkaprt.com/rwd/26/)для классификации каждого браузера или устройствапо медиакатегориям. Медиатипы могут принимать зна-чения: all, braille, embossed, handheld,print, projection, screen, speech, tty и tv.

С некоторыми из этих медиатипов, как, например,print, screen или даже projection, вы уже ра-ботали. Некоторые другие – embossed (для брайлев-ских принтеров) или speech (для голосовых браузе-ров и интерфейсов) – встречаются впервые. Но все этимедиатипы созданы с одной целью: чтобы мы моглилучше проектировать дизайн для каждого типа бра-узера или устройства, просто загружая нужный CSS.Следовательно, устройство с экраном будет игнориро-вать CSS, созданный для медиатипа print, и наобо-рот. А для стилевых правил, которые применимы ковсем устройствам, в спецификации создана супергруп-па all. На практике это означает правку media-атри-бута ссылки:<link rel="stylesheet" href="global.css"

media="all" /><link rel="stylesheet" href="main.css"

media="screen" /><link rel="stylesheet" href="paper.css"

media="print" />

А также создание блока @media в таблице стилей иего привязку к определенному медиатипу:@media screen {body {font-size: 100 %;}}@media print {body {font-size: 15 pt;}}В любом случае спецификация предлагает браузеру

определить, к какому медиатипу он относится. («Я де-сктопный браузер! Я отношусь к медиатипу screen»,«Я пахну чернилами и тонером: я тип print», «Я бра-узер видеоконсоли: я тип tv» и т. д.) Загрузив страни-цу, браузер будет отображать только тот CSS, которыйотносится к определенному медиатипу, и игнорироватьвсе остальные. И – в теории – это потрясающая идея.

Но теория – это, наверное, последнее, что нужно за-нятому по горло веб-дизайнеру.

Неправильное

распределение типов

Когда на сцене появились все эти браузеры дляустройств с маленькими экранами, как, например, те-лефоны или планшеты, с ними пришли и проблемы. Всоответствии со спецификацией решить эти проблемынесложно, нужно просто создать таблицу стилей длямедиатипа handheld:<link rel="stylesheet" href="main.css"

media="screen" /><link rel="stylesheet" href="paper.css"

media="print" /><link rel="stylesheet" href="tiny.css"

media="handheld"/>Проблемы скорее кроются в нас самих, по крайней

мере, частично. На первых мобильных устройствах небыло эффективно работающих браузеров, поэтому мыпросто игнорировали их, разрабатывая вместо этоготаблицы стилей для медиатипов screen или print.А когда такие браузеры появились, в Сети не былодостаточно CSS-файлов типа handheld. В результа-те многие разработчики мобильных браузеров решилииспользовать таблицы стилей для медиатипа screen.

А растущий диапазон мобильных устройств еще

больше усложняет дело. Сможет ли одна и та же та-блица стилей решить все проблемы для iPhone и длятелефона пятилетней давности?

Знакомство с медиазапросами

К счастью, организация W3C включила в специ-

фикацию CSS3 синтаксис медиазапросов, усовершен-ствовав методологию медиатипов. Медиазапросы по-зволяют не только ориентироваться на конкретныйкласс устройств, но и анализировать физические ха-рактеристики устройства, использующегося для ото-бражения страницы (http://bkaprt.com/rwd/27/).

Взгляните на следующий отрывок:@media screen and (min-width: 1024px) {body {font-size: 100 %;}}Каждый медиазапрос, включая и этот, содержит два

компонента:1. Он начинается с медиатипа (screen), взятого

из списка утвержденных медиатипов спецификацииCSS2.1 (http://bkaprt.com/rwd/26/).

2. После типа идет сам запрос в скобках: (min-width: 1024px), который тоже можно разделить надве составляющие: название свойства (min-width) исоответствующее значение (1024px).

Считайте, что медиазапросы просто проверяют ваш

браузер. В процессе считывания таблицы стилей бра-узер получает вопрос от медиазапроса screen and(min-width: 1024px): относится ли он к медиатипуscreen, и если да, то имеет ли он ширину области про-смотра не меньше 1024 пикселей. Если браузер отве-чает на оба вопроса положительно, вложенные в за-прос стили отображаются, в противном случае браузерпопросту игнорирует их и занимается своими делами.

Этот медиазапрос вписан в объявление @media, чтопозволило включить его непосредственно в таблицустилей. Но вы можете также поместить запрос в эле-мент ссылки (link), вставив его в атрибут media:<link rel="stylesheet" href="wide.css"

media="screen and (min-width: 1024px)" />Кроме того, вы можете прикрепить его к инструкции

@import:@import url("wide.css") screen and (min-

width: 1024px);Лично я предпочитаю использовать @media, по-

скольку он хранит ваш код в отдельном файле, умень-шая количество внешних запросов браузера к серверу.

В принципе, неважно, куда вы впишете запрос, ре-зультат будет одинаковым: если браузер соответствуетмедиатипу и при этом выполняет условие, указанное взапросе, вложенные в запрос CSS выполняются, еслинет – игнорируются.

Познакомьтесь с характеристиками

Однако дело не только в том, чтобы проверить ши-

рину и высоту. Запросы могут проанализировать мас-су характеристик, указанных в спецификации. Но пре-жде чем мы приступим к этому делу, давайте сначалаопределимся с терминами, зачастую сложными и не-понятными.

1. В спецификации сказано, что каждое устройствоимеет «область просмотра» (display area) и «площадьизображения» (rendering surface). Ну и что это такое?Переведем на наш язык: окно просмотра браузера –это область просмотра, а весь монитор – площадь изо-бражения. На вашем ноутбуке областью просмотра бу-дет окно браузера; площадью изображения – экран.

2. Чтобы задать определенные значения, некото-рые характеристики могут принимать префиксы min–и max-. Например, вы можете вписать (min-width:1024px) и (max-width: 1024px), чтобы задатьобласть просмотра более или менее 1024 пикселей со-ответственно.

Все понятно? Великолепно. С этим разобрались, да-вайте рассмотрим характеристики, которые в соответ-ствии со спе-цификацией мы можем использовать внаших запросах (http://bkaprt.com/rwd/28/) (табл. 4.1).

А еще мы можем связывать несколько запросов вцепочку, соединяя их словом and:@media screen and (min-device-width:

480px) and (orientation: landscape) { … }То есть мы можем задать несколько характеристик

в одном запросе, выполняя тем самым более сложныйанализ устройства, на котором просматривается нашдизайн.

Знай свои характеристики

Чувствуете себя королем мира? Тогда мне именно

сейчас следует сказать, что не все браузеры, распо-знающие @media, поддерживают создание запросовдля всех характеристик, указанных в спецификации.

Табл. 4.1. Характеристики устройств, тестируемых с использованием

медиазапросов

Вот вам пример. Когда Apple выпустила свой первыйiPad, он поддерживал медиазапрос orientation. Этозначит, что вы могли написать запрос orientation:landscape или orientation: portrait для обслу-живания устройства средствами CSS. Круто, да? К со-жалению, iPhone не поддерживал запрос orientation до

тех пор, пока несколько месяцев спустя не вышло об-новление операционной системы. В то время как всеустройства позволяли пользователю изменить ориен-тацию, браузер iPhone не понимал запросы на эту ха-рактеристику.

Мораль этой истории? Внимательно изучайтеустройства и браузеры на предмет запросов характе-ристик, которые они поддерживают, и проверяйте ихнадлежащим образом.

В то время как поддержка современных браузерови устройств все еще находится в процессе развития,медиазапросы дают нам прекрасную возможность чет-ко сформулировать то, как именно должен выглядетьнаш дизайн на различных устройствах и браузерах.

Более отзывчивый робот

Медиазапросы – это последний элемент отзывчи-

вого веб-сайта. На протяжении двух глав мы делалигибкий макет, который, однако, является всего лишьосновой. Теперь мы можем использовать медиазапро-сы для коррекции любых визуальных дефектов, воз-никающих при изменении формы и размеров областипросмотра.

Кроме того, мы можем использовать медиазапро-сы для оптимизации отображения нашего контента всоответствии с требованиями определенного устрой-ства, создавая альтернативные макеты под опреде-ленные диапазоны разрешений. Загружая правиластилей, касающиеся этих диапазонов, медиазапросыпозволяют нам создавать страницы, более чувстви-тельные к требованиям устройств, которые их отобра-жают.

Другими словами, объединяя гибкие макеты и ме-диазапросы, мы наконец-то сможем сделать наш сайтотзывчивым.

Приступим.

В компании с viewport

Мы уже определили основные пункты, на которые

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

Когда в 2007 году Apple выпустила iPhone, она со-здала новое атрибутивное значение для элементаmeta Mobile Safari: viewport (http://bkaprt.com/rwd/29/).Зачем? Размеры дисплея iPhone – 320 х 480, но MobileSafari фактически отображает веб-страницы шириной980 пикселей. Если вы когда-нибудь заходили на сайтгазеты New York Times (http://nytimes.com) с телефонас функцией WebKit (рис. 4.9), вы могли видеть это вдействии: Mobile Safari рисует страницу на холсте ши-риной 980px, а затем сжимает ее, чтобы уместить наэкране с разрешением 320 х 480.

Рис. 4.9. По умолчанию браузер Mobile Safari воспроизводит контент с

шириной 980px, даже когда вы держите телефон в горизонтальной плос-

кости и ширина ограничена 320px

При помощи тега viewport мы можем контролиро-вать размеры этого холста и задавать точные разме-ры области просмотра браузера. Например, мы можемустановить фиксированную ширину в 320px:<meta name="viewport"

content="width=320" />С того момента, как Apple представила механику

viewport, многие разработчики браузеров принялиее, сделав стандартом де-факто. Давайте попробуемвключить его в наш дизайн, который скоро станет от-зывчивым. Однако вместо того, чтобы устанавливатьфиксированную ширину в пикселях, используем под-ход, не зависящий от разрешения. В блоке head наше-го HTML пишем элемент meta:<meta name="viewport" content="initial-

scale=1.0, width=device-width" />Свойство initial-scale устанавливает уровень

масштабирования страницы на 1.0, или 100 %, чтообеспечивает некоторую согласованность распознаю-щих viewport браузеров, для устройств с маленькимиэкранами. (Более детальную информацию по масшта-бированию под различные мониторы вы сможете най-ти в объяснении Mozilla: http://bkaprt.com/rwd/30/.)

Большое значение для нас имеет параметрwidth=device-width, который делает ширину окнапросмотра браузера равной ширине экрана устрой-ства. Например, на iPhone область макета Mobile Safariуже составляет не 980px, а 320 пикселей в портретномрежиме и 480 – в ландшафтном.

Имея на руках это значение, мы можем использо-вать max-width и min-width для поиска диапазоновразрешений ниже или выше определенного порога изагружать в CSS, предназначенного для этих диапазо-нов. Кроме того, в этом случае браузеры, распознаю-щие запросы, могут воспользоваться ими, что сделаетнаш дизайн отзывчивым для всех пользователей, не-важно, с какого устройства они его просматривают – стелефона, планшета, стационарного компьютера илиноутбука.

Так, что-то я заболтался. Давайте лучше взглянемна пресловутые запросы в действии.

Медиазапросы в действии

Вы помните тот большой внушительный заголовок

(рис. 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. При должном умении заголовок может стать вполне внуши-

тельным

Я упустил несколько презентационных свойств, по-

тому что меня больше заботит то, как этот ужасныйогромный заголовок выглядит при небольшом разре-шении. Он написан торжественным шрифтом LeagueGothic (http://bkaprt.com/rwd/31/) белого цвета (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: 36pxauto). Прекрасно, но давайте добавим правило в ужесуществующий медиазапрос, чтобы подрегулироватьего характеристики при отображении на устройстве сразрешением меньше оригинального:@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&nbsp;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, благодаря чему изображениенемного выходит за рамки с правой стороны.

Как назло, ни один из этих эффектов не будет рабо-тать при низком разрешении. Но я везучий парень. Такчто давайте кое-что допишем в конце нашего медиа-запроса:@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 class="logo"><a href="/"><i><img src="logo.png" alt="Robot or

Not?" /></i></a>

</h1><ul class="nav nav-primary"><li id="nav-blog"><a href="#">The

&#8217;Bot Blog</a></li><li id="nav-rated"><a href="#">Top

Rated</a></li><li id="nav-droids"><a href="#">Droids of

the Day</a></li><li id="nav-contact"><a href="#">Contact

Us</a></li></ul><!– /end ul.nav.nav-primary – >Итак, мы обозначили логотип тегом 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 (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/), браузер, которыйобеспечивает повсеместную поддержку медиазапро-сов. Что не может не радовать.

К сожалению, «повсеместную» совсем не означает

«универсальную». С десктопными браузерами старшетех, которые перечислены, нам не повезло. И InternetExplorer версии 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.

Но это не единственная причина. Компания37signals, разработчик программного обеспечения, не-давно начала проводить эксперименты с отзывчивымдизайном для одного из своих приложений, и вот чтоони сказали по этому поводу (http://bkaprt.com/rwd/39/):

Оказывается, для того, чтобы сайт работална различных устройствах, нужно всего лишьдобавить к конечному продукту несколькомедиазапросов CSS. Если макет изначальноделался «резиновым», то все, что нужно длятого, чтобы он правильно отображался наустройствах с маленькими экранами, – это

сжать несколько отступов и доработатьмакеты боковых панелей.

Другими словами, если у нас есть гибкая основа,нам не придется дописывать много кода. Макеты сфиксированной шириной необходимо переписыватьдля каждого значения разрешения, тогда как дизайны,созданные на основе процентов, а не пикселей, самименяют свои пропорции в зависимости от разрешенияустройства. В этой главе мы научились быстро и изби-рательно удалять или менять свойства макета и, такимобразом, его оптимизировать.

Кроме того, гибкий дизайн лучше подходит к устрой-ствам, которые еще находятся в стадии разработки.Несколько лет назад слово «планшет» ассоциирова-лось у нас исключительно с iPad. Теперь под это опре-деление подходят и такие устройства, как 7-дюймовыйGalaxy Tab компании Samsung, Kindle и Nook, осна-щенные своими браузерами. Мы не сможем угнать-ся за всеми устройствами, появляющимися на рынке.Гибкий дизайн позволит нам не обращать вниманияна отдельные диапазоны разрешений и поможет луч-ше подготовиться к новым, еще не виданным устрой-ствам.

Ограничения по

мере необходимости

Хочу напомнить вам, что никто не разбирается ввашем дизайне лучше вас, даже его пользователи.Поэтому, если вы считаете, что свойство max-widthобеспечит целостность элемента, смело вписывай-те его в код. Вот как описывает компания 37signalsсвои эксперименты с отзывчивым дизайном (http://bkaprt.com/rwd/39/):

Разработчики практически полностьюзабыли такое свойство CSS, как max-width,поскольку его не поддерживал Internet Explorer6. Однако это превосходное дополнение к«резиновому» макету, позволяющее содержаниюестественным образом подстраиваться подразличную ширину страницы, не разрастаясьнастолько, что строчки текста кажутсяабсурдно длинными. Это прекрасный компромиссмежду «резиновым» и фиксированным дизайном.

В настоящее время я работаю над модернизациейпроекта, и у нас возникла дискуссия по поводу этогоограничения. Я задал дизайну фиксированную шири-ну max-width, равную 1200px, – ниже этой отметкион абсолютно гибкий. Вы спросите, почему же не сде-

лать его полностью «резиновым»? Мы потратили до-статочно времени на то, чтобы написать и вставить вкод медиазапросы, благодаря которым сайт выглядитидеальным как в последней версии Chrome, так и нателефоне на базе Android или в браузере Kindle. Чтоже касается дизайна для широкого экрана, мы реши-ли, что овчинка выделки не стоит: у нас просто нет та-ких пользователей. Поэтому и ввели ограничение max-width.

В качестве примера такого единения max-widthи медиа-запросов я могу привести сайт ДэнаСедерхольма (http://simplebits.com) и официальныйблог дизайнерской компании Happy Cog (http://cognition.happycog.com) (рис. 4.24 и 4.25). Это пре-красные примеры того, как «резиновый» макет ограни-чивается пиксельным max-width.

Рис. 4.24. Дэн Седерхольм, дизайнер всех дизайнеров, решил ис-

пользовать max-width 960 пикселей на своем вновь переделанном сайте.

И знаете что? Получилось отлично

Рис. 4.25. Талантливые ребята из Happy создали новый отзывчивый

дизайн, использовав max-width 820 пикселей. Результат? Великолепный!

Некоторые дизайнеры предпочитают именно этотспособ решения проблемы длинных строчек, однакоон не единственный. Зайдите на сайт дизайнера и ил-люстратора Джона Хикса (рис. 4.26), одного из первых,кто в 2010 году переписал свой сайт (http://bkaprt.com/rwd/40/).

Джон пошел другим путем. Он не заморачивалсяс ограничениями, а настроил шрифтовое оформле-ние (font-size) под различные диапазоны расшире-

ний так, чтобы текст хорошо читался на любом экране(рис. 4.27).

Рис. 4.26. Сайт Джона Хикса полностью гибкий и великолепно выгля-

дит при любом разрешении

Рис. 4.27. Вместо того чтобы положиться на max-width, Джон предпо-

чел настроить шрифтовое оформление под различные диапазоны рас-

ширений, что помогает сделать тексты читаемыми и приятными на вид,

вне зависимости от того, на каком устройстве вы читаете его блог

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

Мы как дизайнеры принимаем определенные реше-ния и находим компромиссы между гибкостью и кон-

тролем. Мы спокойно можем делать гибкие макеты иограничивать их элементами с фиксированной шири-ной (рис. 4.28). Так что, когда и если мои клиенты ре-шат, что их аудитория только выиграет от широкофор-матных дизайнов, они смогут убрать ограничение max-width, дописать несколько медиазапросов и получитьнужный результат.

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

Рис. 4.28. Разработанная Джоном Хиксом тема Shelf для WordPress

и Tumblr (http://bkaprt.com/rwd/41/) идеальна с точки зрения гибкости, но

при этом содержит ряд контейнеров с фиксированной шириной. (Обожаю

эту горизонтальную прокрутку!)

5. Как стать отзывчивым

При установлении порядка появились

имена.Поскольку возникли имена, нужно знать

предел [их употребления].Знание предела позволяет избавиться от

опасности.Когда дао находится в мире, [все сущее

вливается в него], подобнотому как горные ручьи текут к рекам и

морям.Дао Дэ Цзин, «стих 32».В переводе Яна Хин Шуна, 1950 г.

Теперь у вас есть все необходимое для успешно-го создания отзывчивых сайтов. Вы научились стро-ить пропорциональную гибкую сетку, изучили несколь-ко стратегий внедрения медиафайлов с фиксирован-ной шириной в ваш дизайн и поняли, как медиазапро-сы могут вывести дизайн за границы мира стационар-ных компьютеров.

И все это время мы рассматривали отзывчивый ди-зайн, так сказать, в своего рода вакууме. Теперь мыизучим несколько способов, которые помогут нам вне-дрить его в работу, а также рассмотрим некоторые ме-тодики усовершенствования уже известных нам техно-логий.

Все дело в контексте

Начав экспериментировать с отзывчивыми дизай-

нами, вы обнаружите, что правильно созданный сайтобеспечивает высокий уровень целостности различ-ных контекстов. Это происходит потому, что на са-мом базовом уровне отзывчивый дизайн адаптируетодин документ HTML к различным браузерам и устрой-ствам, делая страницы более портативными и доступ-ными при помощи гибких макетов и медиазапросов.

Однако некоторые веб-дизайнеры выступают про-тив такого подхода и считают, что для каждого устрой-ства нужно делать отдельную верстку. В своем длин-ном посте, посвященном этому вопросу, разработчикдля мобильных устройств Джеймс Пирс ставит под со-мнения целесообразность подобного дизайна (http://bkaprt.com/rwd/42/):

То, что посетитель сайта используетустройство с маленьким экраном, еще неговорит о том, в каком контексте он егоиспользует. Человек может идти, ехать вмашине или вообще отдыхать на диване.В каждом из этих сценариев посетительзаслуживает различного обслуживания или, покрайней мере, немного переделанных версийосновного сайта.

Более лаконично высказался дизайнер ДжеффКрофт (http://bkaprt.com/rwd/43/):

Как правило, пользователи мобильныхустройств и пользователи стационарныхкомпьютеров неодинаково смотрят на вашпродукт. Если у вас ресторан, то пользователистационарных компьютеров хотят увидеть насайте его фотографии, полное меню и, можетбыть, историю развития. Пользователи жемобильных устройств хотят просто получитьадрес и часы работы.

Давайте рассмотрим эти аргументы более деталь-но. Во-первых, устройство, которое применяет пользо-ватель – мобильное или стационарное, – зависит отконтекста, ситуации, в который пользователь оказал-ся. На основании такого контекста мы можем создатькласс пользователей и наметить несколько целей. Дру-гими словами, посетители, использующие мобильныеустройства, хотят более быстрого доступа, чем еслибы они сидели за стационарным компьютером или но-утбуком, когда время и пропускная способность кана-ла на их стороне.

Во-вторых, если приоритеты и цели пользователяразличны, применять один HTML-документ действи-тельно нецелесообразно. Возьмем пример Джеффа:если на сайте ресторана вверху каждой страницы рас-положены фотографии, то, скорее всего, они находят-

ся в верхней части HTML. А это значит, что пользовате-лю мобильного устройства, на котором отображаетсялинейный вариант той же самой верстки, придется до-статочно долго проматывать страницу, чтобы добрать-ся до времени работы ресторана.

Признаю: я согласен с этими аргументами, но доопределенного момента. Да, по устройству вполне се-бе можно предположить обстановку, в которой нахо-дится пользователь, но это всего лишь предположе-ние. Например, я довольно часто выхожу в сеть с мо-бильного телефона, сидя при этом на диване у себядома. И это не еще одна шутка про то, что у меня дру-гой жизни, кроме Интернета, не имеется: исследова-ния показали, что достаточно много людей пользуютсямобильной Сетью и в стенах собственного дома (http://bkaprt.com/rwd/44/, http://bkaprt.com/rwd/45/).

Я не говорю, что на контекст не нужно обращать вни-мания или что вообще не стоит задумываться о такихвещах. Но мы не можем судить об обстановке, окружа-ющей пользователя, по устройству, которое он исполь-зует. Зачастую таких представлений, созданных на ба-зе контекста, недостаточно, чтобы получить желаемуюинформацию (рис. 5.1). Дизайнеры не должны пола-гаться на столь удобное разделение устройств на «мо-бильные» и «стационарные» – это всего лишь терми-ны, они не заменят полного анализа аудитории вашегосайта. Значение имеют не только устройства и браузе-

ры, которые они используют, но и как, где и зачем ониих используют.

Рис. 5.1. При просмотре на iPad сайты Google Reader и Twitter по

умолчанию предстают в «мобильном» виде. Отличный дизайн, но пра-

вильно ли он применяется в этом контексте?

Но самое главное в том, что отзывчивый веб-дизайни не должен заменять мобильные сайты. Это скореефилософия дизайна, стратегия разработки внешнихинтерфейсов. То есть в первую очередь необходимопонять, целесообразно ли его использование при ра-

боте над определенным проектом. Возможно, есть об-основанные причины для создания отдельных версий(мобильной и стационарной) одного и того же сайта, аможет быть, ваш контент лучше представить, приме-нив отзывчивый дизайн. Решать только вам и вашимпользователям. Я согласен с теми дизайнерами, ко-торые говорят, что определенные пользователи опре-деленных сайтов заслуживают получения отдельногоконтента. Но я также считаю, что многие сайты толь-ко выиграют от обслуживания различных контекстов иустройств одним документом. К созданию таких сайтови нужно подходить с точки зрения отзывчивости.

Так как же узнать, нужен ли вам отзывчивый дизайн?

Определение целей пользователей

В начале 2010 года я работал над сайтом Cog’aoke

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

Рис. 5.2. Пример Cog’aoke. Два различных контекста – два разных

сайта

Мы решили, что мобильная версия сайта должнасовершенно отличаться от десктопной. Мы понимали,что зашедшие на сайт люди хотят быстро и легко ори-ентироваться в происходящем. Кроме того, мы собира-лись сделать живое голосование и предложить поль-зователям проголосовать за понравившихся исполни-телей в определенное время – и все это на мобильной

версии сайта.Мы рассматривали десктопную версию как первич-

ную, предварительную подготовку к самому событию.Мобильная версия же предназначалась именно длявечера шоу, для пользователей, которые физическитам присутствовали. Следовательно, цели этих двухконтекстов были абсолютно разными.

Прекрасно понимая это, мы могли бы включить вкаждую страницу сайта для любого контекста всюразметку. Если бы мы это сделали, каждая страни-ца мобильной версии сайта содержала бы весь обыч-ный «десктопный» контент, включая карту, указания иинформацию о голосовании. Мы, конечно, могли быиспользовать комбинацию медиазапросов и свойстваdisplay: none для того, чтобы соответствующаяверсия отображалась на соответствующем устрой-стве.

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

Знакомьтесь:

«Сначала мобильные»

Когда у вас появится свободная минутка (и креп-кий алкоголь под рукой), зайдите к Мерлину Манну ипосмотрите его подборку Noise to Noise Ratio (http://bkaprt.com/rwd/46/). Там представлены самые насы-щенные контентом страницы, они просто утопают вхламе. А саму статью, оба ее параграфа, найти прак-тически невозможно.

Даже если вы раньше не видели сайты из галереиМерлина, бьюсь об заклад, что проблемы, которые тампредставлены, вам вполне знакомы. Более того, я счи-таю, что эта тенденция подпитывает некоторые нашипредубеждения о создании сайтов для «мобильных»пользователей. Мы предполагаем, что им нужно да-вать меньше контента, поскольку они менее толерант-ны, чем пользователи стационарных компьютеров. Упоследних есть внушительных размеров экраны, удоб-ное кресло и больше времени и желания найти то, чтоим нужно.

Но даже если у них есть такая возможность, неуже-ли им это нужно? Другими словами, почему быстрыйдоступ к ключевым элементам дается только мобиль-ным пользователям? Почему все пользователи не мо-

гут получать нужный им контент легко и быстро?В конце 2009 года дизайнер Люк Вроблевски про-

извел небольшую революцию в нашей профессии,предположив, что мобильное представление сайтов недолжно ограничиваться второстепенной ролью (http://bkaprt.com/rwd/47/). Ссылаясь на резкий рост мобиль-ного веб-трафика и новые технические возможностисовременных телефонов, Люк предложил веб-дизай-нерам создавать в первую очередь мобильные версиисайтов и приложений.

«Сначала мобильные» – это прекрасная дизайнер-ская философия. Более того, я считаю, что она простобесценна для проектов отзывчивого дизайна, над ко-торыми я работаю. Развитие браузеров и устройств ирост интереса наших клиентов к сайтам, разработан-ным не только для стационарных компьютеров, даетнам прекрасную возможность взглянуть на нашу про-фессию со стороны – на работу и язык, на вопросы,которые мы задаем, и решения, которые принимаем.

Навстречу отзывчивому

процессу разработки

Мы в самом начале пути. Многие дизайнеры, сту-дии и агентства еще только начинают изучать отзыв-чивый дизайн. Поэтому у нас не так уж много практи-ческого опыта. Со временем это изменится, мы ста-нем мыслить более отзывчиво. А пока, мне кажется,я смог поделиться некоторыми моими наработками вэтой сфере. Возможно, они вам пригодятся, и вы на-верняка сможете их усовершенствовать.

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

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

Наверное, можно было бы выразить это более за-влекательно и интересно, но вообще-то маркетинг не

мой конек. Мы стали задавать такие вопросы, потомучто считаем, что подход «сначала мобильные» неверо-ятно полезен в процессе создания веб-сайта. Вот какЛюк объясняет смысл этого подхода (http://bkaprt.com/rwd/48/):

Если вы разрабатываете дизайн вначаледля мобильного телефона, вы создаете основу,которую можете использовать при созданииверсии сайта для стационарного компьютера/ноутбука. Если мы включаем в мобильноепредставление самый нужный и важный длянаших клиентов и бизнеса контент, то почемуего нужно менять с увеличением пространстваэкрана?

Легко заполнить окно десктопного браузера панеля-ми инструментов социальных сетей, ссылками на по-хожие статьи, RSS-ссылками и облаками тегов. (Еслия не ошибаюсь, то это называется «созданием допол-нительной ценности».) Но как только мы вынужденыработать с экраном, размеры которого на 80 % мень-ше, чем наш обычный холст, несущественный контенти всякий хлам быстро отпадают, и мы можем сосре-доточиться на действительно важных аспектах нашихпроектов.

Другими словами, создавая дизайн для мобильныхустройств в первую очередь, дизайнеры приобретаютуникальный опыт, поскольку сосредотачиваются на са-

мом главном, а в современном веб-дизайне это ред-кость. Это не означает, что сайт должен содержать ми-нимум информации. Но, задав себе в самом началепроизводственного процесса этот простой вопрос, мыможем критически оценивать каждый предложенныйэлемент, каждую новую часть функциональности.

Определяем разрешение

Процесс создания дизайна начинается с определе-

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

Табл. 5.1. Список устройств с различным разрешением

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

делить объем работ и область применения. Зная, ка-кие устройства будут использоваться для отображениянашего дизайна, мы можем более эффективно выпол-нять свою работу.

Когда список готов, можно приступать к самому ди-зайну.

Итеративный совместный дизайн

В настоящее время бо́льшая часть проектов стро-

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

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

Но работа над отзывчивым сайтом несколько отли-чается по содержанию и может сделать таким обра-зом организованный процесс громоздким и неповорот-ливым. Давайте представим, что вам нужно переде-

лать сайт из одной страницы. Вы набросали макет всвоем любимом приложении. Но как вы сообщите сво-ему клиенту, как эта страница будет выглядеть на те-лефоне? Или на iPad? Или на широком экране? Еслиу вас есть время, бюджет и люди, вы можете спокойносделать дизайн каждого дополнительного устройства,отдать их на рассмотрение клиенту, получить коммен-тарии и в соответствии с ними исправить каждый ва-риант. Но если вы делаете пятнадцать или пятьдесятстраниц, такой подход выглядит непрактичным.

В процессе работы над последними проектами с от-зывчивым подходом я обнаружил, что, если объеди-нить этапы проектирования и разработки, такая кол-лективная работа будет более эффективной. Я назы-ваю этот новый этап «проектоработкой». (Шутка.)

Вначале команда дизайнеров представляет макетстраницы всей группе. Как правило, это дизайн длястационарных компьютеров (рис. 5.3), хотя иногда мыможем начать с мобильного представления дизайна.Цель заключается в том, чтобы дать всей группе им-пульс для обсуждения того, как этот дизайн будет со-гласоваться с различными диапазонами разрешенийи типами ввода. Возникают самые разнообразные во-просы: «Как это слайд-шоу будет работать с сенсор-ным интерфейсом?», «Этот модуль всегда будет свер-нутым по умолчанию или пользователи стационарныхкомпьютеров увидят больше информации?», «Как этот

элемент станет выглядеть (и функционировать), еслив браузере не будет JavaScript?»

Рис. 5.3. Начнем с изучения готового дизайна для стационарного ком-

пьютера и попробуем понять, каким образом он должен измениться для

различных браузеров или устройств

Отвечая на эти вопросы, участники группы обмени-ваются идеями, обсуждают, как дизайн будет функцио-нировать на различных устройствах, и изучают особен-но сложные элементы взаимодействия. Если какая-ни-будь часть нуждается в доработке, этим занимаетсякоманда дизайнеров. Но если группа чувствует себякомфортно, а доработки совсем незначительны, то ко-манда разработчиков приступает к созданию первона-чального варианта, прототипа.

«И это до окончательного утверждения дизайна?»– спросите вы. Да. Наша цель состоит в том, чтобывыйти за пиксельные ограничения Photoshop и начатьвоплощать дизайн, который будет менять свои разме-ры в зависимости от размеров окна браузера. Поэто-му команда разработчиков приступает к созданию от-зывчивого дизайна: преобразовывает фиксированнуюсетку в «резиновую», обсуждает способы гибкого пред-ставления различных медиатипов и использует медиа-запросы для адаптации нашего дизайна к различнымдиапазонам разрешений.

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

как, например, Web Developer Toolbar для Firefox иChrome (http://bkaprt.com/rwd/49/), на этом этапе могутбыть исключительно полезны. Если у вас есть списокразрешений (табл. 5.1), вы можете сохранить их в рас-ширении для быстрого доступа в будущем (рис. 5.5).

Рис. 5.4. Как я уже говорил, изменение размеров окна браузера по-

зволяет быстро протестировать качество дизайна. Но это лишь первый

шаг

Рис. 5.5. Меню Resize в Web Developer Toolbar позволяет изучить со-

держимое в разрешениях для различных устройств

Но вспомните: в предыдущей главе мы говорили отом, что изменение размеров окна браузера – это толь-ко промежуточный этап. Если вы действительно хоти-те проверить, как ваша страница будет отображать-

ся на том или ином устройстве, ничто не заменит са-мо устройство. (Если вы интересуетесь приложениемдля тестирования на мобильных устройствах, я насто-ятельно рекомендую вам почитать статью Питера-По-ла Коха Smartphone Browser Landscape («Многообра-зие браузеров для смартфонов»), которую вы сможетенайти на A List Apart: http://bkaprt.com/rwd/50/. В прин-ципе, даже если вы не собираетесь покупать кучу раз-ных телефонов, все равно почитайте, оно того стоит).

На этом этапе начинает прорисовываться прототип.Он основан на оригинальном макете, созданном ко-мандой дизайнеров, но в процессе написания кодаразработчики дают свои рекомендации по поводу то-го, как этот дизайн должен реагировать на различныеустройства. Другими словами, разработчики действу-ют как дизайнеры, просто они работают в другой сре-де и рассматривают дизайн с точки зрения браузера, ане Photoshop. Затем эти рекомендации обсуждаются,проверяются и анализируются всей командой.

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

Интерактивный анализ дизайна

Перед общим собранием разработчики загружают

страницу прототипа в различные целевые устройства(рис. 5.6), а на самом собрании представляют ее всейгруппе. Целью этого этапа является испытание прото-типа и анализа отображения страницы на ноутбуках истационарных компьютерах, телефонах и планшетах.Члены команды меняют размеры окон браузера, из-учают фотогалереи и проверяют, насколько удобно вы-полнять различные действия на устройствах с клавиа-турой и с сенсорными экранами.

Рис. 5.6. Устройства, применяемые при тестировании сайтов в jQuery

Mobile (Filament Group, Inc.)

Эти эксперименты с прототипом проходят в руслесодержательной дискуссии. Я считаю, что для коман-ды разработчиков полезно будет заранее составитьсписок проблем, которые возникли в процессе созда-ния отзывчивого дизайна. Возможно, они заметили, чтона сенсорном экране тяжело попасть в какую-нибудьважную ссылку или что анимация отображается слиш-ком медленно в каком-нибудь десктопном браузере.Определяя области интересов и потенциальные кам-

ни преткновения, разработчики подготавливают поч-ву для конструктивного обсуждения функционально-сти дизайна и его общего впечатления.

Цель такого собрания – анализ «живого» дизайна.Оригинальный макет – это примерный план с правила-ми разметки, инструкцией по типографике и библиоте-кой шаблонов, который команда разработчиков долж-на превратить в отзывчивый дизайн. Другими слова-ми, мы проверяем рекомендации разработчиков и об-суждаем, есть ли необходимость в дальнейшей дора-ботке. Это может быть полный пересмотр оригиналь-ного макета или всего лишь некоторые незначитель-ные изменения. После собрания обе команды расхо-дятся со своими новыми задачами, и все повторяетсяс начала. Анализ, дизайн, разработка и повторение.

Вот гипотетический пример того, как это работает.Например, команда дизайнеров сделала макет модуляглобальной навигации с двумя ключевыми ссылками иполем поиска.

С этим макетом в руках команда разработчиков на-чинает встраивать навигацию в шаблон (рис. 5.7).

Рис. 5.7. Так будет выглядеть только что спроектированная строка на-

вигации на экране десктопа

Довольно простой дизайн предусматривает двессылки, расположенные в ряд, и поле поиска с пра-вой стороны от них. При создании отзывчивого дизайнаразработчики решили, что для устройств с маленькимиэкранами будет более эффективно, если поле поисказаймет всю ширину страницы, а ссылки расположатсяпод ним (рис. 5.8).

Рис. 5.8. Для устройств с более мелким разрешением ссылки поме-

щены ниже строки поиска

На этапе анализа дизайна несколько дизайнероввысказались в том смысле, что более мелкая версиясовсем неудобна. Строка поиска слишком заметна изатмевает собой ссылки. Кроме того, когда они началитестировать дизайн на различных устройствах, то, пы-таясь нажать на ссылку на сенсорных телефонах, по-падали в поле поиска.

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

Рис. 5.9. После обсуждения проблемы дизайнеры решили использо-

вать для проблемной строки навигации другой вариант

Рис. 5.10. Окончательный вид строки навигации, созданный дизайне-

рами и разработчиками после нескольких попыток

Это только один небольшой пример того, как идеттакая совместная работа. Взаимодействие дизайне-ров и разработчиков должно быть постоянным. Обе ко-манды должны периодически проверять свою работу идавать ее на рассмотрение другой. Работая над теку-щим проектом, наши дизайнеры и разработчики встре-чаются каждую неделю и выполняют его интерактив-

ный анализ, но в течение недели они также обменива-ются эскизами кода или дизайна.

В конечном счете мы хотим объединить тради-ционные циклы «проектирования» и «разработки» идать возможность двум группам сотрудничать на такойблизкой основе, которая позволит им создать эффек-тивный отзывчивый дизайн. Работая над текущим про-ектом, наши дизайнеры и разработчики, конечно, ис-пользуют для проектирования дизайна такие програм-мы, как Photoshop, но более динамичный подход заста-вил их обратиться к нашему реальному холсту: брау-зеру.

Ответственный подходк отзывчивому дизайну

В процессе проектирования/разработки мы постоян-

но исправляем и совершенствуем страницы для дости-жения конечной цели – получения готового к производ-ству шаблона. Вот тут мы и обнаружили, что филосо-фия «сначала мобильные» может быть невероятно по-лезной при создании отзывчивого дизайна.

В этой книге на базе сайта Robot or Not мы проде-монстрировали, как объединенные возможности «ре-зиновой» сетки, гибких изображений и медиазапросовобеспечивают более отзывчивый подход к созданиюсайтов. Сначала мы взяли фиксированный макет, раз-работанный в Photoshop, и превратили его в «резино-вую» сетку. В четвертой главе мы обсудили, какие про-блемы возникают при изменении размеров окна брау-зера, поскольку наш первоначальный дизайн не пред-назначался для разных размеров окна браузера. Что-бы решить эти проблемы, мы ввели медиазапросы исоздали альтернативные макеты для маленьких и ши-роких экранов. И наконец, для браузеров, которые неподдерживают медиазапросы, мы включили библиоте-ку respond.js для доступа к нашим альтернативнымвариантам дизайна.

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

Рис. 5.11. Нет медиазапросов? Нет JavaScript? Выглядит ужасно –

наш гибкий и предназначенный для больших компьютеров дизайн начи-

нает на небольших экранах распадаться на части

Кроме того, существует еще одна проблема со струк-турой сайта. Взгляните на небольшой кусочек CSS:.blog {background: #F8F5F2 url("img/blog-

bg.png") repeat-y;}@media screen and (max-width: 768px) {.blog {background: #F8F5F2 url("img/noise.gif");}}Во-первых, мы включили фоновое изображение, а

именно двухцветную картинку blog-bg.png, которуюиспользовали во второй главе для создания иллюзиидвух колонок, в элемент .blog. Затем для малень-ких экранов с шириной менее 768px мы вместо этогоразместили простой размноженный GIF, поскольку мысделали эти более узкие страницы линейными.

Возникающая в этом случае проблема заключаетсяв том, что некоторые мобильные браузеры, особенноMobile Safari на iPhone и iPad, фактически загружаютобе картинки, даже если в итоге отображаться на стра-нице будет только одна. А поскольку пропускная спо-

собность канала на мобильных устройствах неболь-шая, мы наказываем их пользователей лишним тяже-лым изображением, которое к тому же еще и не ото-бразится.

К счастью, в отзывчивом дизайне эти проблемыуспешно решаемы, нужно только продумать способ,как это сделать.

«Сначала мобильные»

и медиазапросы

В общих чертах, отзывчивый дизайн предназначендля отображения в определенном диапазоне разреше-ний, тогда как медиазапросы должны адаптировать егок другим диапазонам. Более ответственный подход котзывчивому дизайну означает создание таблицы сти-лей с точки зрения идеологии «сначала мобильные».Таким образом, мы начинаем с определения макетадля устройств с маленькими экранами, а затем исполь-зуем медиазапросы для расширения дизайна с увели-чением разрешения.

Я даже применил этот подход при создании свое-го личного сайта-портфолио (http://ethanmarcotte.com).По умолчанию контент представлен в линейной мане-ре, предназначенной для отображения в первую оче-редь на мобильных устройствах и в узких окнах бра-узера (рис. 5.12). С расширением области просмо-тра сетка становится более сложной и асимметрич-ной (рис. 5.13). И наконец, в самом широком вариантераскрывается «полный» дизайн: разметка становитсяеще более сложной, появляются некоторые тяжелыеэлементы, как это абстрактное фоновое изображение(рис. 5.14).

Рис. 5.12. Дизайн, созданный по умолчанию для небольших экранов

Рис. 5.13. При расширении области просмотра дизайн становится

сложнее

Рис. 5.14. При максимальном расширении дизайн становится виден

полностью благодаря применению медиазапросов

Дизайн все еще отзывчив. В нем есть все, что мыобсудили к настоящему времени: разметка основанана «резиновой» сетке, а изображения прекрасно мас-штабируются. Но, в отличие от сайта Robot or Not, яиспользовал медиазапросы min-width, чтобы увели-

чить дизайн по мере расширения окна просмотра. Ба-зовая структура таблицы стилей выглядит примернотак:/* Default, linear layout */.page {margin: 0 auto;max-width: 700px;width: 93 %;}/* Small screen! */@media screen and (min-width: 600px) { … }/* «Desktop» */@media screen and (min-width: 860px) { … }/* IT’S OVER 9000 */@media screen and (min-width: 1200px)

{ … }Основная часть таблицы содержит правила, связан-

ные с цветом и типом, что предоставляет всем пользо-вателям базовый (но, мы надеемся, все еще привлека-тельный) дизайн. Затем в медиазапросе установленочетыре диапазона разрешений для минимальной ши-рины области просмотра в 480, 600, 860 и 1200 пик-селей. При увеличении расширения сверх этих значе-ний применяются соответствующие правила. Если жесайт открыть браузером, который не поддерживает ме-диазапросы, он отобразится в первоначальном «одно-колоночном» виде, при условии, что патч на JavaScript

недоступен (рис. 5.15).

Рис. 5.15. Никаких медиазапросов? Никакого JavaScript? На этот раз

никаких проблем

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

дизайн.

Концепция прогрессивного

улучшения

Примером такого подхода может стать недавняя мо-дернизация сайта студии мобильного дизайна Yiibu(http://yiibu.com). Основатели Yiibu Брайан и СтефаниРиджер назвали эту модернизацию слиянием подхода«сначала мобильные» и отзывчивого дизайна и доба-вили кое-что от себя (http://bkaprt.com/rwd/52/):

Основное содержание и стандартноепредставление сделано и оптимизированодля отображения в первую очередь насамых простых устройствах. Мы назвалиэто «базовой» поддержкой. Устройствас маленькими экранами, поддерживающиемедиазапросы, получают более расширеннуюверстку и иногда более сложное содержание.Это «мобильная» поддержка. И, наконец,«десктопный» макет и контент отображаютсяна устройствах с широкими экранами.

Термины, конечно, немного отличаются, но прекрас-но пересекаются с оригинальной концепцией прогрес-сивного улучшения Ника Финка и Стивена Чампиона(http://bkaprt.com/rwd/53/):

В отличие от идеи постепенного уменьшения

возможностей, концепция прогрессивногоулучшения использует веб-технологии как слои,которые накладываются на основной контент ифункциональность сайта, предоставляя любойпрограмме или человеку простой доступ кконтенту, а для более «продвинутых» браузеровдемонстрирует еще и дополнительныеэффекты и стили.

С 2003 года, когда Ник и Стивен придумали этоттермин, прогрессивное улучшение было отличитель-ным признаком ответственного подхода к основанномуна стандартах веб-дизайну. Начиная с написания се-мантической, правильно структурированной разметки,приправленной CSS и сценарием DOM посредствомJavaScript, где это необходимо, мы можем создать убе-дительный дизайн для различных браузеров, при этомгарантируя универсальный доступ к контенту, скрыто-му под дизайном.

Стивен Хэй также высказался в пользу прогрессив-ного улучшения в своем прекрасном эссе There is noMobile Web («Нет никакой мобильной Сети») (http://bkaprt.com/rwd/54/):

Большинство сайтов в Сети создано безучета сценария мобильного использования.Однако миллионы людей заходят на этисайты именно с таких устройств. Ониполучают доступ к «нормальному» (чтобы

это ни означало) веб-сайту через «мобильное»устройство.

…Честно говоря, я могу вспомнить

несколько сценариев использования сайтовили приложений, которые были или должныбыли быть полностью мобильными. Судяпо всему, благодаря мобильной Сети мымысленно возвращаемся к тем разговорамо вовлечении, прогрессивном улучшении идоступности, которые мы вели несколько летназад.

У вас случались такие моменты, когда кто-то вдругвзял и четко объяснил, почему вы верите в то, во чтоверите? В своем эссе Стивен в точности указал всепричины, по которым мне так нравится отзывчивыйвеб-дизайн. Вместо того чтобы вкладывать наш кон-тент в различные сайты, предназначенные для различ-ных устройств, мы можем использовать прогрессивноеулучшение, чтобы гарантировать качественный доступдля всех, с расширенным представлением для более«продвинутых».

Работа с JavaScript

Рис. 5.16. Слайд-шоу или, точнее, его подобие

Прежде всего, давайте обратим внимание на слайд-шоу в верхней части сайта Robot or Not (рис. 5.16).В настоящее время разметка выглядит следующимобразом:<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 – >Совсем не впечатляет, да? К тому же еще и не очень

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

То есть нужно включить немного JavaScript и при-дать нашему дизайну некоторую интерактивность. Нодля начала нам нужны слайды! Так что давайте най-дем еще пару изображений и допишем HTML:<div class="slides"><div class="figure"><b><img src="img/slide-robot.jpg"

alt="" /></b><div class="figcaption">…</div></div><!– /end.figure – ><div class="figure"><b><img src="img/slide-tin.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 – >Используя тот же самый модуль .figure, вставим

еще четыре слайда.Выглядит это, конечно, немного странно, посколь-

ку все наши слайды накладываются друг на друга(рис. 5.17). Чтобы привести слайд-шоу в нормаль-ное состояние, воспользуемся бесплатным jQuery-плагином, разработанным Мэтом Маркизом (http://bkaprt.com/rwd/55/). Это один из самых функциональ-ных скриптов слайд-шоу, которыми я когда-либо поль-зовался. К тому же он прекрасно обходится со слай-дами, содержащими различное количество текста илиизображений, без обращения к замысловатой CSS-ми-шуре. (Да, я сказал «мишуре», и я вполне серьезен.)

Рис. 5.17. Мы добавляем новые слайды и начинаем ненавидеть ста-

тичные картинки

Нашему скрипту "карусели" не хватает еще трехэлементов script:<script src="jquery.js"></script><script src="carousel.js"></script><script src="core.js"></script>Поскольку скрипт Мэтта требует запуска jQuery, я за-

грузил библиотеку с http://jquery.com и поместил ее вверхнюю часть страницы (jquery.js), за которой сле-дует скрипт Мэта (carousel.js) и файл core.js, гдемы и напишем код для слайд-шоу.

Кстати, он совсем простой. Впишем в core.js сле-дующие строчки:$(document). ready(function() {$(".welcome.slides").wrapInner(‘<div class="slidewrap"><div

id="welcome-slides" class="slider"></div></div>’).find(".slidewrap").carousel({slide: ‘.figure’});});Ничего страшного, если вам не нравится JavaScript

или вы прежде не использовали jQuery. Этот скрипт

выполняет следующие действия.1. Он располагает элемент div.slides внутри мо-

дуля .welcome при помощи CSS-ориентированногосинтаксиса jQuery ($(".welcome.slides")).

2. Затем обрамляет контент необходимой разметкой(.wrapInner(…))

3. Запускает функцию .carousel(), создаваяслайд-шоу. А поскольку мы присвоили отдельнымслайдам класс .figure, мы дали указания скрипту ихиспользовать.

Эти восемь строчек JavaScript дают нам в результа-те прекрасно работающее слайд-шоу (рис. 5.18). Ура!

Рис. 5.18. Нам удалось оживить слайд-шоу!

Загружаем контент

не спеша, но с умом

По крайней мере, нам есть с чего начинать. Еслимы в браузере отключим JavaScript, мы вернемся к то-му, с чего начинали: слайды накладываются друг надруга, а меню навигации тут просто для красоты. Тоесть любой посетитель сайта, у которого нет доступак JavaScript, получит невнятное и неправильное пред-ставление. Что ж, давайте решим эту проблему.

Для начала уберем навигацию «вперед/назад» изразметки и вставим ее через JavaScript:$(document). ready(function() {var sNav = [‘<li><a class="prev" href="#welcome-

slides">Previous</a></li>’,‘<li><a class="next" href="#welcome-

slides"> Next</a></li>’,‘</ul>’].join("");$(".welcome.slides").wrapInner(‘<div class="slidewrap"><div

id="welcome-slides" class="slider"></div></div>’).find(".slidewrap")

.append(sNav)

.carousel({slide: ‘.figure’});});Теперь код выглядит более сложным, но мы на са-

мом деле ввели только одну новую часть функци-ональности. Прежде всего мы заявили переменнуюsNav, которая содержит HTML для навигации слайдов,и вставили ее перед функцией carousel(). Благода-ря тому, что мы использовали jQuery для вставки нави-гации в страницу, пользователи без JavaScript не смо-гут ее увидеть. Прогрессивное улучшение в действии.

Но это не решает проблему накладывания слайдоводин на другой. И здесь мы немного схитрим: мы убе-рем со страницы все слайды, кроме одного, и переме-стим их в отдельный HTML-файл. Теперь основа на-шей страницы выглядит значительно легче:<div class="slides"><div class="figure"><b><img src="img/slide-robot.jpg"

alt="" /></b><div class="figcaption">…</div></div><!– /end.figure – ></div><!– /end.slides – >Но мы создали отдельный файл (давайте назовем

его slides.html) и вставили в него разметку для че-

тырех оставшихся слайдов.<div class="figure"><b><img src="img/slide-tin.jpg" alt="" /

></b><div class="figcaption">…</div></div><!– /end.figure – ><div class="figure"><b><img src="img/slide-statue.jpg"

alt="" /></b><div class="figcaption">…</div>…</div><!– /end.figure – >Вы, вероятно, заметили, что slides.html – это да-

же не полноценный HTML-документ. Это на самом де-ле отрывок, мини-документ, в котором мы можем со-хранить часть HTML-кода и использовать его позже.Фактически мы воспользуемся jQuery, чтобы открытьslides.html и загрузить изображения в слайд-шоу:$(document). ready(function() {$.get("slides.html", function(data) {var sNav = [‘<ul class="slide-nav">’,‘<li><a class="prev" href="#welcome-

slides">Previous</a></li>’,‘<li><a class="next" href="#welcome-

slides">Next</a></li>’, ‘</ul>’].join("");

$(".welcome.slides").append(data). wrapInner(‘<div

class="slidewrap"><div id="welcome-slides"class="slider"></div></div>’).find(".slidewrap").append(sNav).carousel({slide: ‘.figure’});});});На этом ставим точку. Функция jQuery .get () от-

крывает наш HTML-отрывок (slides.html) и вставля-ет его содержание в модуль при помощи append().Если JavaScript недоступен или если jQuery не можетзагрузить этот файл, то пользователь увидит одну кар-тинку в верхней части страницы: абсолютно приемле-мый вариант для нашего дизайна (рис. 5.19).

Рис. 5.19. Нет JavaScript? Никаких проблем. Слайд-шоу сокращается

до размеров одной картинки, которая все равно отлично выглядит

Дальнейшие улучшения

Наш простой скрипт пополнился кодом, но конечный

результат выглядит более надежно и функционально.Мы не принимаем во внимание возможности браузераили устройства, отображающего нашу страницу: еслиJavaScript доступен, на экране появится слайд-шоу.

Но нет предела совершенству, и этот небольшойчерновой образец – не исключение. Например, мы мо-гли бы сделать так, чтобы слайд-шоу появлялось толь-ко на определенных типах экранов, то есть указатьв скрипте определенные диапазоны разрешений. Так,если мы не хотим, чтобы оно отображалось на устрой-ствах с маленькими экранами, мы могли бы вставить вскрипт простую проверку разрешения:if (screen.width > 480) {)$(document). ready(function({ … });}Этот оператор if выполняет те же функции, что

медиазапрос min-width: 480px: если экран уже480px, вложенный JavaScript не будет применяться(рис. 5.20).

Рис. 5.20. Мы решили, что слайд-шоу станет доступным только для

браузеров с разрешением свыше 480px. На более мелких экранах будет

видна одна-единственная картинка

Пойдем еще дальше. Например, мы можем исполь-зовать легковесный JavaScript-загрузчик LabJS (http://labjs.com/) или Head JS (http://headjs.com/) для дина-мической загрузки jQuery, плагина «карусель» и на-шего собственного custom.js для применения толь-ко в том случае, когда разрешение экрана достигаетопределенных значений. Благодаря этому пользовате-ли устройств с маленькими экранами не окажутся за-валенными лишним JavaScript, особенно если это пре-пятствует загрузке «карусели». А поскольку мы учи-тываем пропускную способность канала, мы можемиспользовать фантастическую библиотеку «отзывчи-

вых изображений», написанную Filament Group (http://bkaprt.com/rwd/56/). На устройства с маленькими экра-нами она выдает более легкие картинки, а на обычные,широкоэкранные – полноразмерные.

Вперед! Будь отзывчивым!

Я упомянул эти расширения совсем не потому, что

это единственный правильный и нужный подход. Ввек портативных точек доступа с 3G и телефонов,оснащенных Wi-Fi, мы не можем на основании разме-ров экрана делать вывод о пропускной способностиустройств. Но при необходимости вы всегда сможетеиспользовать эти расширения.

И все же я считаю, что решать связанные с функ-циональностью проблемы необходимо с точки зренияфилософии «сначала мобильные». Если я не подпус-каю к хитрому интерфейсу мобильных пользователей,то какой от него прок для моей остальной аудитории?Если вы думаете, что это некорректный вопрос, знай-те: легких ответов здесь нет.

Дело в том, что для успеха в веб-дизайне необходи-мо уметь задавать правильные вопросы. Отзывчивыйвеб-дизайн – это возможное решение, способ сделатьдизайн более приспособленным к врожденной гибко-сти Сети. В первой главе я говорил, что отзывчивыйдизайн состоит из «резиновой» сетки, гибких изобра-жений и медиазапросов. Но на самом деле это всеголишь слова, которые мы используем, чтобы озвучитьрешения проблем, с которыми сталкиваются пользо-

ватели, описать рамки для упорядочивания контента впостоянно увеличивающемся море устройств и брау-зеров.

Если мы будем интересоваться потребностями на-ших пользователей и внимательно применять эти ком-поненты, отзывчивый веб-дизайн станет сильной иустойчивой технологией.

С нетерпением жду того момента, когда вы будетерассказывать мне свои истории создания отзывчивогодизайна.

Благодарности

У меня не хватит слов и места, чтобы должным обра-

зом выразить свою благодарность тем людям, которыеповлияли на всю мою работу, не говоря уже об этойкниге. И все же попытаюсь.

Прежде всего, я бесконечно благодарен владельцамсайта A Book Apart за то, что они заинтересовалисьотзывчивым дизайном и дали мне возможность напи-сать мою первую книгу. Джейсон Санта-Мария уделилбеспрецедентное внимание деталям и качеству. Мэн-ди Браун – очень умный и проницательный редактор,и я бесконечно благодарен ей за помощь и терпениев придании книге ее окончательного вида. И конечно,мое сердечное спасибо Джеффри Зельдману за егострастные статьи и неустанную работу, и за все те воз-можности, которые появились у меня благодаря егоидеям.

Если я иногда могу сказать что-то внятное, то этотолько благодаря Гаррету Кайзеру.

Питер-Пол Кох, Брайан и Стефани Риджер, Джей-сон Григсби и Стивен Хей научили меня всему, что язнаю о дизайне для мобильных устройств, и неимовер-но укрепили мою веру в отзывчивый дизайн. А техно-логия Люка Вроблевски «сначала мобильные» бесцен-

на для любого дизайна – отзывчивого или фиксирован-ного.

Хой Винь и Марк Болтон поведали нашему сообще-ству, и мне в том числе, много интересных и нужныхфактов из истории нашей профессии. Более того, «ре-зиновая» сетка была бы невозможна без ранних иссле-дований Ричарда Раттера.

Если бы более десяти лет назад я не прочитал вели-колепную статью Джона Олсоппа A Dao Of Web Design(«Дао веб-дизайна»), мое представление о Сети былобы совершенно другим, а эта книга никогда не появи-лась бы на свет.

Дэвид Слейт, команда Filament Group (Пэтти Толэнд,Тодд Паркер, Мэгги Костелло и Скотт Джел) и Мэт Мар-киз оказали неоценимую помощь на ранних этапах на-писания этой книги. Кроме того, компания Filament да-ла мне прекрасную возможность модернизировать ди-зайн крупного проекта, и от этого выиграл не только я,но и эта книга.

Техническая редакция Дэна Седерхольма былавдумчивой, основательной и веселой. Как и он сам.

Я даже не могу выразить словами, насколько япольщен тем, что Джереми Кит согласился написатьпредисловие. Черт, «польщен» даже близко не стоялос тем, что я чувствую.

Моя семья – родители, братья, сестры и бабушка –поддерживали меня все это время. Я люблю вас, ре-

бята.И конечно, моя жена Элизабет. Все в моей жизни, и

эта книга тоже, для нее.

Приложение

Полные веб-адресаупомянутых в книге источников

Глава 1

1. http://www.dolectures.com/speakers/craig-mod/2. http://www.flickr.com/photos/

carabanderson/3033798968/3. http://www.alistapart.com/articles/dao/4. http://www.morganstanley.com/institutional/

techresearch/mobile_internet_report122009.html5. http://vimeo.com/148996696. http://vimeo.com/148994457. http://www.smartglassinternational.com/8. http://vimeo.com/4661618

Глава 2

9. http://meyerweb.com/eric/tools/css/reset/

Глава 3

10. http://www.flickr.com/photos/

uberculture/1385828839/11. http://clagnut.com/sandbox/imagetest/12. http://www.svendtofte.com/code/max_width_in_ie/13. http://msdn.microsoft.com/en-us/library/

ms532969.aspx14. http://www.dillerdesign.com/experiment/

DD_belatedPNG/15. http://msdn.microsoft.com/en-us/library/

ms532920(VS.85). aspx16. http://unstoppablerobotninja.com/entry/fluid-images17. http://www.yuiblog.com/blog/2008/12/08/

imageopt-5/18. http://www.alistapart.com/articles/fauxcolumns/19. http://stopdesign.com/archive/2004/09/03/liquid-

bleach.html20. http://www.w3.org/TR/css3-background/#the-

background-size21. http://srobbin.com/jquery-plugins/jquery-

backstretch/22. http://www.bbc.co.uk/news/technology-1194868023. http://bryanrieger.com/issues/mobile-image-

replacement/

Глава 4

24. http://www.w3.org/TR/CSS2/media.html25. http://www.alistapart.com/articles/goingtoprint/26. http://www.w3.org/TR/CSS21/media.html#media-

types27. http://www.w3.org/TR/css3-mediaqueries/28. http://www.w3.org/TR/css3-mediaqueries/#media129. http://developer.apple.com/library/safari/

#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html

30. https://developer.mozilla.org/en/Mobile/Viewport_meta_tag#Viewport_basics

31. http://www.theleagueofmoveabletype.com/fonts/7-league-gothic

32. http://windows.microsoft.com/ie933. http://ie.microsoft.com/testdrive/HTML5/

CSS3MediaQueries/34. http://www.quirksmode.org/mobile/#t1435. http://blogs.msdn.com/b/iemobile/

archive/2011/02/14/ie9-coming-to-windows-phone-in-2011.aspx

36. http://www.quirksmode.org/m/css.html#t02137. http://code.google.com/p/css3-mediaqueries-js/38. https://github.com/scottjehl/Respond

39. http://37signals.com/svn/posts/2661-experimenting-with-responsive-design-in-iterations

40. http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign

41. http://thethemefoundry.com/shelf/

Глава 5

42. http://tripleodeon.com/2010/10/not-a-mobile-web-

merely-a-320px-wide-one43. http://jeffcroft.com/blog/2010/aug/06/responsive-

web-design-and-mobile-context/44. http://thefonecast.com/News/tabid/62/EntryId/3602/

Mobile-shopping-is-popular-when-watching-TV-says-Orange-UK-research.aspx

45. http://www.lukew.com/ff/entry.asp?126346. http://www.flickr.com/photos/merlin/

sets/72157622077100537/47. http://www.lukew.com/ff/entry.asp?93348. http://www.lukew.com/ff/entry.asp?111749. http://chrispederick.com/work/web-developer/50. http://www.alistapart.com/articles/smartphone-

browser-landscape/51. http://www.flickr.com/photos/

filamentgroup/5149016958/52. http://yiibu.com/about/site/53. http://www.hesketh.com/publications/

inclusive_web_design_for_the_future/54. http://www.the-haystack.com/2011/01/07/there-is-

no-mobile-web/55. http://matmarquis.com/carousel/

56. http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/

57. http://en.wikipedia.org/wiki/Canons_of_page_construction

58. http://www.amazon.com/dp/0520250125/59. http://www.amazon.com/dp/3721201450/60. http://www.amazon.com/gp/product/0321703537/61. http://www.fivesimplesteps.com/books/practical-

guide-designing-grid-systems-for-the-web62. http://www.markboulton.co.uk/journal/comments/a-

richer-canvas63. http://www.thegridsystem.org/64. http://www.alistapart.com/articles/fluidgrids/65. http://www.w3.org/TR/css3-mediaqueries/66. https://developer.mozilla.org/En/CSS/

Media_queries67. https://github.com/filamentgroup/Responsive-

Images68. http://unstoppablerobotninja.com/entry/responsive-

images/69. http://filamentgroup.com/lab/

responsive_images_experimenting_with_context_aware_image_sizing/70. http://clagnut.com/blog/268/71. http://bryanrieger.com/issues/mobile-image-

adaptation72. http://www.alistapart.com/articles/dao73. http://adactio.com/journal/1716/

74. http://adactio.com/journal/4443/75. http://timkadlec.com/2011/03/responsive-web-

design-and-mobile-context/76. http://globalmoxie.com/blog/mobile-web-

responsive-design.shtml77. http://www.cloudfour.com/weekend-reading-

responsive-web-design-and-mobile-context/78. http://unstoppablerobotninja.com/entry/with-good-

references/79. http://unstoppablerobotninja.com/entry/toffee-

nosed/

Рекомендуемая литература

Jan Tschichold. The New Typography. University of

California Press, 2006.Josef Müller-Brockmann. Grid Systems in Graphic

Design. Verlag Niggli AG, 2008.Khoi Vinh. Ordering Disorder: Grid Principles for Web

Design. New Riders Press, 2010.Mark Boulton. A Practical Guide to Designing Grid

Systems for the Web. Five Simple Steps, 2009.

Помощь онлайн

Вопросы применения сетки для веб-дизайна рас-

сматриваются в следующих источниках:• Запись в блоге Марка Болтона A Richer Canvas:

http://bkaprt.com/rwd/62/• Веб-сайт The Grid System: http://bkaprt.com/rwd/63/• Моя статья для A List Apart о гибкой сетке (Fluid

Grids): http://bkaprt.com/rwd/64/Если вы ищете информацию о медиазапросах, то

следующие две ссылки – это действительно фантасти-ческое чтение:

• Спецификации медиазапросов World Wide WebConsortium (W3C): http://bkaprt.com/rwd/65/

• Справочные материалы разработчиков Mozilla натему медиазапросов: http://bkaprt.com/rwd/66/

Если вы работаете с изображениями и другимисредствами медиа в гибкой среде, рекомендую вамдля ознакомления:

• Скрипт Responsive Images от Filament Group: http://bkaprt.com/rwd/67/, а также соответствующие запи-си в блоге: http://bkaprt.com/rwd/68/, http://bkaprt.com/rwd/69/

• Эксперименты Ричарда Раттера с изменениямиразмеров изначальных изображений: http://bkaprt.com/

rwd/70/• Эксперименты Брайана Ригера с адаптацией изо-

бражений: http://bkaprt.com/rwd/71/Дополнительную информацию, как и когда взять на

вооружение подход отзывчивого дизайна, можно найтиздесь:

• Семинар Джона Олсоппа A Dao of Web Design:http://bkaprt.com/rwd/72/

• Статья Люка Вроблевски на тему «Сначаламобильные»: http://bkaprt.com/rwd/47/, а также ста-тьи на его сайте: http://www.lukew.com/ff/archive.asp?tag&mobilefirst

• Работы Джереми Кита One Web: http://bkaprt.com/rwd/73/ и Context: http://bkaprt.com/rwd/74/

• Запись Тима Кадлека в статье Responsive WebDesign and Mobile: http://bkaprt.com/rwd/75/

• Блоги Джоша Кларка и Джейсона Григсби. Джош(http://bkaprt.com/rwd/76/) и Джейсон (http://bkaprt.com/rwd/77/) постоянно ведут интересную дискуссию, кото-рая поможет вам понять, в каких случаях и для какихпроектов необходим отзывчивый дизайн.

• Мои записи в блогах With Good References (http://bkaprt.com/rwd/78/) и Toffee-Nosed (http://bkaprt.com/rwd/79/).

Об авторе

Итан Маркотт – разносторонний дизайнер-разработ-чик. Его работы – это сочетание качественного ко-да и захватывающего дизайна. Среди его клиентов –New York Magazine, Стэнфордский университет, кино-фестиваль «Сандэнс» и Консорциум Всемирной пау-тины (World Wide Web Consortium, W3C). Он ведет блогhttp://unstoppablerobotninja.com и постоянно зависает в«Твиттере» (@beep).

Итан – автор и технический редактор A List Apart,журнала для людей, делающих веб-сайты. Он по-пулярный лектор, он выступал на конференциях AnEvent Apart, SXSW Interactive Festival («Интерактивныйфестиваль SXSW»), Future of Web Design («Будущеевеб-дизайна») и AIGA’s In Control («Контроль в рукахAIGA»).

Вместе с основателем Happy Cog Джеффри Зельд-маном Итан работал над третьей редакцией книги«Web-дизайн по стандартам» (New Riders, 2009), кото-рая занимает почетное место на книжных полках всехопытных дизайнеров. Кроме того, он участвовал в на-писании таких книг, как Handcrafted CSS («CSS ручнойработы») (New Riders, 2009), Web Standards Creativity(«Творчество и стандарты Сети») (friends of ED, 2007)и Professional CSS («Профессиональные CSS») (Wrox,2005).

«Отзывчивый веб-дизайн» – первая самостоятель-ная книга Итана, он безумно рад тому, что она увиде-

ла свет, и хотел бы поблагодарить вас за то, что вы еепрочитали.