otzyvchivyyvebdizayn

Более современные браузеры, такие как 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.AlphaImageLoaderpath/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. Говоря техническим языком, эти изображения слишком круп-ные и массивные

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

Навстречу отзывчивости К счастью, Консорциум Всемирной паутины (WorldWide 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 не понимал запросы на эту ха-рактеристику. Мораль этой истории? Внимательно изучайтеустройства и браузеры на предмет запросов характе-ристик, которые они поддерживают, и проверяйте ихнадлежащим образом. В то время как поддержка современных браузерови устройств все еще находится в процессе развития,медиазапросы дают нам прекрасную возможность чет-ко сформулировать то, как именно должен выглядетьнаш дизайн на различных устройствах и браузерах.