Актуальные книги для тех, кто создает сайты - Отзывчивый веб-дизайн

Итан Маркотт

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

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

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

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

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

Об этом говорит и автор «Отзывчивого веб-дизайна». Он погружает вас в мир адаптивных веб-сайтов – сайтов, которыми удобно пользоваться независимо от того, какое устройство сейчас в вашем распоряжении. Сегодня эта концепция – не прихоть, а важный тренд развития Сети. И речь идет не просто о «тянущемся» сайте, а о его «умном» приспособлении к любому устройству. Пользователю, который удобно расположился за большим экраном, вы покажете сразу несколько колонок текста. Тому же, кто зашел на ваш сайт с 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-3PO[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-код:

Achieve sentience with Skynet! Read More »

Заголовок с включенной в него ссылкой – прекрасная основа для семантической разметки, не правда ли? После обнуления стилей вы получаете в браузере следующий результат (рис. 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

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

font size 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. Схема расположения элементов для нашего блога}

Мы можем быстро и ловко перевести его схему в базовую структуру верстки:

Recently in The Bot Blog

…

<!– /end.main – >

…

<!– /end.other – >

<!– /end.blog.section – >

<!– /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,628888889

331 / 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

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

Lo, the robot walks

Ничего особенного: элемент

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, main object

). Если изображения или другие медиафайлы появятся в этом списке, они станут гибкими, в противном случае – останутся в своем отсталом пиксельном состоянии.

Таким образом, если вы все еще работаете с морально устаревшими версиями 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, Firefox 3+ и 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/), который позволяет добавлять масштабируемые фоновые изображения для элемента 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. Любой посетитель сайта будет в восторге от нашего исковерканного дизайна (это сарказм)}

Примечания

1

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

2

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

Конец бесплатного ознакомительного фрагмента.