Статьи

Основы адаптивной типографики

Автор: Оливер Райхенштайн (OLIVER REICHENSTEIN), 1 июня 2012
Оригинал: http://ia.net/blog/responsive-typography-the-basics/
Адаптированный перевод: Егор Стремоусов, 1 ноября 2013

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

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

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

  1. Адаптивный макет: пошаговое изменение макета под ограниченное число размеров экрана.

  2. Резиновый макет: когда макет использует всю доступную ширину экрана.

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

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

Выбор шрифта

Правильный характер

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

Мы разработали свой собственный шрифт для нашего сайта с целью проведения адаптационных экспериментов. Мы выбрали шрифт с засечками, поскольку это соответствует нашему характеру и отражает изысканность наших материалов (по крайней мере, нам так кажется). Для iA Writer мы использовали моноширинный шрифт. Поскольку главной целью этого приложения является помощь в написании черновика, мы умышленно взяли Nitti — шрифт, который делает текст сильным и, в тоже время, аккуратным. Решение использовать моноширинный шрифт было продиктовано еще и тем фактом, что операционная система первого iPad не имела автоматического кернинга для пропорциональных шрифтов. Вместо того, чтобы использовать пропорциональный шрифт, который будет плохо смотреться, мы решили запустить приложение в жизнь с моноширинным шрифтом.

С засечками или без?

Обычно жребий падает между шрифтом с засечками и шрифтом без засечек. Сам по себе это сложный вопрос, но есть одно правило, которое может вам помочь: «Шрифт с засечками — это священник, а без засечек — хакер». Это не значит, что один лучше другого. Нет, просто по ряду причин антиква лучше передает авторитарные ощущения, а гротеск более демокартичен. Учтите, что пять тысяч лет типографского дела уместились в одно это кривое определение, поэтому не стоит относится к нему слишком серьезно.

Многие люди считают, что вопрос «с засечками или без» для экранной типографики уже давно решен. На самом деле, не все так просто. Вопреки распространенному мнению обе категории шрифтов могут хорошо работать, если вы выберите для основного текста размер шрифта больше 12 пикселей. Шрифты с засечками меньше 12 пикселей теряют четкость отрисовки. К тому же для современных мониторов 12 пикселей уже определенно мало. И это плавно переносит нас к следующему пункту.

Какой размер?

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

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

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

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

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

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

Высота строки и контраст

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

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

iPhone vs iPad

Все, что мы узнали про адаптивную типографику, пришло из процесса поиска идеальной типографики в нашем приложении. Когда мы разрабатывали iA Writer для iPad, мы потратили несколько недель на разработку правильных параметров текста. Тогда высокое разрешение экрана iPad стало для нас испытанием, которое потребовало определенного времени на преодоление. Когда Apple встроила retina-дисплеи в iPad и iPhone, все началось заново. Мы могли бы написать целую книгу о том, как получили канонический вид шрифта в iA Writer, но пока есть так много, что нужно рассказать о более общих вещах, я попридержу коней.

Если вы сравните текущую версию iA Writer для iPhone с версией для iPad, вы можете заметить, что размер шрифта в них разный.

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

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

  2. Экран iPhone меньше, и приходится учитывать это ограничение.

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

Поскольку iPhone преподносится к лицу ближе, а размер экрана у него меньше, то высота строки также уменьшается:

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

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

А что с настольными компьютерами?

Некоторые люди жаловались на слишком большой шрифт в Writer для Mac. Точно так же, как мы нашли оптимальный размер шрифта для iPad (среди множества дистанций для чтения), мы нашли подходящий размер шрифта и для Mac. Тогда мы проводили тесты на 24-дюймовом iMac с высоким разрешением экрана, на котором воспринимаемый размер шрифта более или менее соответствовал всем другим устройствам.

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

Вы можете спросить: «Почему вы не позволили пользователю самому определять размер шрифта?». Потому что размер шрифта не зависит от вкусовых предпочтений человека, а определяется дистанцией чтения. Поскольку большинство сайтов и приложений используют небольшой размер шрифта, новые пользователи с самого начала будут устанавливать привычный им маленький размер и никогда не смогут испытать настоящее удовольствие от работы с нашим приложением. Наша цель не в том, чтобы добиться одинакового отображения у всех пользователей, а в том, чтобы iA Writer работал без настроек и без лишних заморочек, позволяя сосредоточится лишь на написании текстов. Такой подход является ключом к успеху этой программы и, если его поменять, пропадет сама суть приложения. (Что действительно стоит улучшить, так это доступность для людей с ограничениями по зрению).

Хорошо, но почему бы тогда не подстраиваться под разрешение экрана автоматически? Не будет ли это действительно адаптивной типографикой? Все верно, и мы уже работаем в этом направлении. Но сейчас, помимо адаптации к разрешению экрана необходимо также выбирать правильный оптический вес текста, чтобы быть уверенным, что шрифт работает именно так, как и задумывалось, во всех размерах и разрешениях. С изменением размера шрифта поменяется также и оптическое восприятие текста. Вот почему версии iA Writer для Mac, iPad 1/2 и iPad3 отличаются друг от друга. Чтобы объяснить логику адаптации шрифтов полностью, а также наши соображения, которыми мы руководствовались при разработке нового сайта, мне потребуется немного больше времени и пространства. Так что ждите продолжение!

Отзывы

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

«@iA Дочитал до фразы „проектирование взаимодействия — это инженерная деятельность“. Что это значит?» @bokardo

На случай, если кому-то еще будет интересно… Полная цитата звучит так:

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

Обычно я говорю:

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

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

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

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

Резюмируя, можно сказать, что в процессе проектирования сайтов и приложений, большую часть времен мы думаем о компромиссах и выбираем из всех зол наименьшую. Это то, что выбивает большинство графических дизайнеров из колеи, поскольку они привыкли к тотальному контролю. Больше информации об этом вы можете почерпнуть в великолепной презентации Чои Вина (KHOI VINH) «Разница между графическим и экранным дизайном» (2007).

Стандартный
Статьи

Секретная симфония: подробное руководство по удобочитаемой типографике в вебе

Автор: Крис Пирсон (CHRIS PEARSON), декабрь 2011
Оригинал: http://www.pearsonified.com/2011/12/golden-ratio-typography.php
Перевод: Егор Стремоусов (28 декабря 2011)

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

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

Математическая симфония типографики

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

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

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

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

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

Вывод из этого:

Математические пропорции типографики — это жизненно важный фактор для восприятия сайта и его содержания.

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

Три фундаментальных типографских параметра

Каждый параграф текста, который вы видите, имеет 3 основных измеряемых параметра. Первые два, размер шрифта и высота строки — измеряются по вертикали.

Рисунок 1 — Как размер шрифта и высота строки представлены в браузерах.
Размер шрифта — это расстояние от верней точки заглавной буквы (S) до нижней границы нижних выносных элементов (y). Высота строки делится пополам и равномерно распределяется сверху и снизу от центра строки.

Третий параметр, длина строки, измеряется по горизонтали.

Рисунок 2 — Высота и длина строки — это вертикальная и горизонтальная метрики типографики.

Эти три параметра вместе определяют то, как вы воспринимаете текст.

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

Ниже, на рисунке 3, высота и длина строки зафиксированы, а размер шрифта изменяется от 13 до 16 пикселей.

Рисунок 3 — С фиксированными высотой и длиной строки становится ясно, что чем большие размер шрифта, тем больше требуется высота строки для сохранения пропорций и удобочитаемости.

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

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

Размер шрифта и высота строки имеют прямо пропорциональную зависимость.

В следующем примере размер шрифта и высота строки фиксированные, а длина строки варьируется от 233 до 466 пикселей.

Рисунок 4 — По мере увеличения длины строки чтение текста затрудняется, поскольку высота строки не увеличивается для компенсации эффекта чрезмерной ширины.

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

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

Эти выводы подтверждают проведенные исследования. В 2004 году Мэри Дайсон (MARY C. DAYSON) из Института Чтения (какая ирония, да?) установила, что:

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

Что это значит для нас? Это означает, что высота и длина строки имеют определенную математическую зависимость, а конкретно:

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

Но каков математический смысл этого соотношения?

Гармоничные пропорции и золотое сечение

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

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

Что же это за удивительные пропорции, которые «склеивают осколки этого мира»?

Конечно же, я говорю о золотом сечении.

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

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

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

Математика золотого сечения типографики

Как вы уже, наверное, догадались, ответом является решительное «да»! И вот как это работает.

Во-первых, размер шрифта (f) и высота строки (l) соотносятся через коэффициент подобия (h). Базовое математическое уравнение выглядит следующим образом:

Согласно этому уравнению, оптимальная высота строки получится в том случае, если коэффициент подобия h будет равен золотому сечению φ. Это дает нам следующее уравнение:

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

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

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

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

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

Эти уравнения примечательны тем, что впервые подводят под параметры текста прочную математическую основу.

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

Однако, тут есть небольшая проблема: веб не настолько точен, как эти уравнения.

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

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

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

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

Тонкая настройка золотого сечения типографики для веба

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

Для шрифта с размером 16 пикселей идеальная высота строки получается тогда, когда коэффициент h равен золотому сечению (≈1.61 — Прим. переводчика). Это дает оптимальное значение для высоты строки, равное 25.88854 пикселя. Используя это значение, вы можете вычислить, что соответствующее оптимальное значение для длины строки равно 670.21670 пикселя.

Если вы попробуете использовать эти значения в вашем CSS-коде, то столкнетесь с рядом проблем.

Поскольку разрешены только целочисленные значения, веб не сможет отобразит высоту строки, равную 25.88854 пикселя. В лучшем случае высота строки станет равна 26 пикселям.

Но 26 пикселей — это больше, чем оптимальная высота строки, полученная из уравнения. А как мы уже знаем, нельзя изменять высоту строки (даже на чуть-чуть!) без изменения соответствующей длины строки (в противном случае конечные пропорции не будут «золотыми»).

Поэтому операция округления высоты строки с 25.88854 до 26 пикселей требует, чтобы конечная длина строки должна быть больше, чем 670.21670 пикселя.

Эту суть корректировки параметров типографики:

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

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

Рисунок 5 — Для сохранения геометрических пропорций и удобочитаемости вместе с увеличением длины строки должна увеличиваться ее высота. Серая линия на этом графике представляет золотое сечение (φ), а цветные — изменение высоты строки относительно этого значения для наиболее распространенных размеров шрифта.

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

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

  1. скорректированную высоту строки, зная размер шрифта и длину строки;

  2. или скорректированную длину строки, зная размер шрифта и высоту строки.

Вычисления проводим при помощи следующих уравнений:

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

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

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

  • Что, если вы захотите использовать шрифт в 16 пикселей для текста шириной 550 пикселей?

  • Какой должна быть высота строки в этом случае?

Вы можете решить эту задачу следующим образом:

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

Калькулятор золотого сечения типографики

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

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

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

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

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

Если вы укажите и размер шрифта, и длину строки, то получите целый набор:

  • Оптимизированные параметры типографики для вашего размера шрифта и длины строки.

  • Лучшие значения параметров типографики для длины строки, которую вы указали.

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

  • Оптимальные значения типографики для указанного размера шрифта.

Попробуйте поиграть с калькулятором золотого сечения и познайте невиданное качество типографики!

Особое значение золотого сечения типографики

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

Золотое сечение типографики можно использовать для любого текста в любой среде.

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

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

Заключение

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

Запомнили математическую симфонию типографики?

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

Стандартный
Статьи

О верстке вертикального ритма

Ритм в теории музыки — соотношения длительностей
звуков (нот) в их последовательности.

— Википедия

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

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

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

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

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

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

Расчет интересующей нас высоты линейного блока происходит по следующему алгоритму:

  1. Определяется высота каждого строчного блока в линейном блоке.

  2. В соответствии со свойством vertical-align строчные блоки выстраиваются по вертикали.

  3. Определяется высота линейного блока как расстояние от верхней границы самого верхнего строчного блока до нижней границы самого нижнего блока.

Следует помнить, что пустые строчные блоки так же влияют на расчет высоты линейного блока, поскольку, несмотря на отсутствие содержимого, имеют внутренние и внешние отступы (padding и margin), границу (border), высоту строки (line-height), а также заданные размеры (width и height).

Таким образом, значимыми CSS-свойствами для расчета высоты линейного блока являются:

  • padding-top, padding-bottom

  • margin-top, margin-bottom

  • border-top, border-bottom

  • height

  • font-size

  • line-height

  • vertical-align

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

Padding, margin, border

Свойства padding-top, padding-bottom, margin-top, margin-bottom, border-top и border-bottom не увеличивают высоту строчного блока на собственное значение, однако учитываются при расчете высоты линейного блока.

Height

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

Line-height и font-size

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

Важно понимать, что свойства line-height и font-size связаны между собой понятием интерлиньяжа.

В CSS, интерлиньяж — это разница между размером шрифта и вычисляемым значением line-height. Эта разница в виде свободного пространства распределяется сверху и снизу от отображаемых глифов поровну (дробные значения округляются до целых). Образованные части называются половинным интерлиньяжем.

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

Vertical-align

Свойство vertical-align смещает строчные блоки внутри линейного блока по вертикали, «растягивая» его высоту

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

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

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

Пример из жизни

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

Для определения требуемых стилевых правил воспользуемся упомянутым выше (или любым другим) генератором вертикального ритма.

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

Причина проблемы в выравнивании по базовой линии (навязано набором правил из reset css) и фиксированном line-height (определен генератором). Уменьшение размера шрифта ведет к увеличению половинного интерлиньяжа и к смещению второго строчного блока вниз, что, в свою очередь, приводит к увеличению высоты линейного блока.

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

Ссылки по теме

Генераторы вертикального ритма:

http://topfunky.com/baseline-rhythm-calculator/
http://drewish.com/tools/vertical-rhythm
http://toki-woki.net/p/Boks/
http://baselinecss.com/

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

http://www.alistapart.com/articles/settingtypeontheweb
http://webtypography.net/Rhythm_and_Proportion/Vertical_Motion/2.2.1/
http://24ways.org/2006/compose-to-a-vertical-rhythm
http://thegrids.ru/literature/31
http://habrahabr.ru/blogs/typography/78322/

Стандартный
Статьи

Превентивный AJAX

Заработался, блин.
Залез на порно-сайт…..
Забыл, зачем залез, и начал выкачивать исходники их страниц, дабы посмотреть как у них реализован Ajax на сайте =(

— bash.org.ru/quote/393929

Про технологию AJAX широко заговорили в далеком 2005 году после запуска сервиса Google Maps и Google Search Suggestions. Тогда же с легкой руки Adaptive Path и Джесси Гаррета (JESSE JAMES GARRET) появился и сам термин «Асинхронный JavaScript и XML». Сокращенно — AJAX.

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

Эта была чистой воды контекстная адаптация к изменяющимся целям пользователей и превентивная реакция на их действия.

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

И дальше началось. Все кинулись делать свои сайты быстрее, современнее, мощнее.

В сети появилось множество статей, раскрывающих всю «сложность» кроссбраузерной реализации «новой» технологии (96 года). Полки магазинов быстро заполонили книги типа «AJAX и PHP», которые несомненно покупались и окупались. Этот информационный бум в свою очередь породил толпы «программистов на АЯКСЕ», которых по убогости можно сравнить разве что только с «программистами на jQuery».

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

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

Апогеем AJAX-эпопеи можно назвать дыры растерянности в головах обычных людей, оставшиеся после hash-bang-модификаций и без этого не всегда понятных URL-ов. Парадигму полностью скриптовых сайтов подхватили мастодонты интернет-пространства типа Twitter’а и сервисов Google, задав курс и темпы развития для игроков поменьше.

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

Технология переросла в моду.

И что в итоге? Мы как ждали того момента, когда страница загрузится, так ждем и сейчас. Только теперь мы ждем асинхронной доставки контента без перезагрузки страниц. По всему интернету полно крутящихся и извивающихся прелоадеров!

Хочется спросить, а где же реальная польза от AJAX?

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

Но ведь это все не видно нашим клиентам, не так ли?

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

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

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

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

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

Стандартный
Статьи

Адаптивный веб-дизайн

Автор: Этан Мэркотт (ETHAN MARCOTTE)
Иллюстрации: Кевин Корнэлл (KEVIN CORNELL)
Оригинал: http://www.alistapart.com/articles/responsive-web-design/ (25 мая 2010)

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

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

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

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

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

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

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

Мы можем изолировать мобильные версии сайтов по разным поддоменам, отдельно огородить «сайты не под iPhone». Но что дальше? «Сайт под iPad»? «Сайт под N90»? Можем ли мы на самом деле продолжать брать на себя обязательства по поддержке каждого нового устройства с уникальными параметрами взаимодействия?

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

Гибкая основа

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

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

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

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

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

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

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

Начинаем реагировать

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

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

В своей книге «Интерактивная архитектура» Майкл Фокс (MICHAEL FOX) и Майлс Кемп (MILES KEMP) описывают этот более гибкий способ организации пространства как «многозвенную систему, к которой кто-то подключается для общения; постоянный и конструктивный обмен информацией».

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

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

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

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

Знакомьтесь, это — Media Query

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

<link rel="stylesheet" type="text/css" href="core.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

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

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

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

Например, после недавнего роста и улучшения мобильного WebKit, media queries стали популярной клиентской техникой отдачи специализированных таблиц стилей для iPhone, Android-телефонов и ему подобных. Чтобы добиться этого, мы можем добавить media query в атрибут media для соответствующей таблицы стилей:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />

Media query состоит из двух частей:

  1. media type (screen)
  2. и, собственно, сам запрос в скобках, содержащий конкретную media feature (max-device-width) и ее точное значение (480px) для проверки.

Мы как бы спрашиваем устройство о том, меньше или равно его разрешение по горизонтали (max-device-width), чем значение в 480 пикселей.

Если тест пройден успешно (т.е., мы просматриваем верстку на устройстве с маленьким экраном, как, например, у iPhone), то устройство подгрузит себе файл shetland.css. В противном случае ссылка на эти таблицы стилей будет проигнорирована.

Дизайнеры и раньше экспериментировали с макетами, поведение которых зависело от разрешения экрана. В основном эти опыты опирались на такие JavaScript-решения, как великолепный скрипт Кэмерона Адамса (CAMERON ADAMS).

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

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

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />

Кроме того, мы не ограничены в добавлении media queries только в тег link. Мы можем добавить их непосредственно в CSS-код, как часть правила @media:

@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

Или как часть директивы @import:

@import url("shetland.css") screen and (max-device-width: 480px);

В любом случае эффект один и тот же. Если устройство проходит тест, заданный нашим media query, то соответствующий CSS-код применяется к верстке.

Проще говоря, media queries — это своего рода условные комментарии. Вместо того, чтобы ориентироваться на конкретную версию конкретного браузера, мы можем в режиме реального времени вносить изменения в верстку макета, если она при масштабировании выходит за пределы базового/идеального разрешения.

Адаптация, реакция и преодоление

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

.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
width: 31.121642969984202211%;             /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}

Я специально опустил ряд типографических свойств, чтобы сфокусироваться на блочной модели. Каждый элемент с классом .figure занимает примерно треть от ширины родительского контейнера. К тому же последнее изображение в каждом ряду имеет нулевой правый внешний отступ (li#f-mycroft, li#f-winter).

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

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

@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

Если вы посмотрите на новый вариант страницы с нашим примером в современном браузере, при этом сделав ширину окна менее 600 пикселей, то media query отключит свойство текучести у основных структурных блоков и поставит их в одну линию друг над другом.

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

@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 48.341232227488151658%;          /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

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

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

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

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

@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 13.902053712480252764%;          /* 88px / 633px */
}
}

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

Указав большее значение для min-width в новом media query,
мы можем расположить наши изображения в один ряд.

И это только начало.

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

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

Но адаптивный дизайн не ограничивается изменениями в раскладке страницы. Media queries позволяют нам заниматься невероятно тонкой настройкой этих изменений. Мы можем:

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

Технические моменты

Следует отметить, что media queries имеют хорошую поддержку во всех современных браузерах.

Браузеры Safari 3+, Chrome, Firefox 3.5+ и Opera 7+, а также Opera Mobile и мобильный WebKit, имеют встроенные парсеры media queries (в старых версиях этих браузеров такой поддержки нет). И хотя Microsoft взяла на себя обязательства по поддержке media queries в 9 версии Internet Explorer, на данный момент их реализацией этот браузер похвастаться не может*.

*На момент написания статьи Internet Explorer 9 еще не вышел в релиз. В 9-ойверсии браузера от Майкрософт обещанная поддержка была полностью реализована. — Прим. переводчика.

Однако, если вас интересует реализация поддержки возможностей media queries в старых браузерах, то вот вам JavaScript-овые лучики надежды:

  • jQuery-плагин 2007 года выпуска предлагает несколько ограниченную реализацию media queries, в которой используются только свойства min-width и max-width, добавляемые в тег link.
  • Недавно разработанная библиотека css3-mediaqueries.js, которая обещает «научить IE 5+, Firefox 1+ и Safari 2 парсить, тестировать и применять CSS3 Media Queries» путем подключения их через блоки @media. Несмотря на то, что версия библиотеки еще только «1.0», мне она показалась довольно стабильной, и я планирую следить за ее дальнейшей разработкой.

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

Только вперед

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

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

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

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

Об авторе

Этан Мэркотт — веб-дизайнер и разработчик, которого глубоко волнуют красивый дизайн, элегантный код, а также их взаимное пересечение. На протяжении нескольких лет Этан имел удовольствие работать с такими заказчиками, как the Sundance Film Festival, Stanford University, New York Magazine and The Today Show.

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

Его последняя книга называется «Адаптивный веб-дизайн».

Стандартный
Статьи

Это не адаптивная веб-разработка, это — адаптивный веб-дизайн

Автор: Франциско Инхосте (FRANCISCO INCHAUSTE)
Оригинал: http://www.getfinch.com/finch/entry/its-not-responsive-web-building-its-responsive-web-design/ (11 августа 2011)

elasticman

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

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

mediaqueries

Mediaqueri.es — свежая галерея, специализирующаяся на адаптивном дизайне.

Я не видел перспективы для АВД сквозь призму проектирования взаимодействия, хотя он и может быть полезным. Мы жили с ним какое-то время, бросались им вокруг, писали посты в стиле «Как это сделать», тестировали разные штуки, и теперь у нас есть галерея примеров (нам еще предстоит узнать, «правильные» они или нет). Он есть и остается частью нашей индустрии.

Круги АВД

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

Круг «АВД — это метод»

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

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

Для этого круга считается нормальным задвинуть такую фразу: «Известно, что люди приходят посмотреть содержание сайта разными способами. Поэтому, вместо того, чтобы заниматься гаданием на кофейной гуще или разрабатывать 15 версий одного сайта (и потом каждый раз соглашаться на доработку чего-то нового), давайте просто сделаем эту хрень адаптивной» [1].

Круг «АВД — это философия»

Для этого круга характерна следующая точка зрения: АВД спасает нас от фиксированной ширины и грехов типа «наилучшее отображение в [Название_Бразуера]». Один из самых больших сторонников АВД, Джефри Зельдман (JEFFREY ZELDMAN) дает такое определение:

«…это очередной этап эволюции в веб-разработке и проектировании взаимодействия. Как с практической точки зрения, так и для всей индустрии
в целом.»

Люди из этого круга считают, что это не просто инструмент или практический метод. Это философия для всего, что связано в веб-дизайном. Что подразумевается под этим? Имеется ввиду сущность АВД. Он является неотъемлемой частью веб-дизайна. В общем случае, когда мы разрабатываем сайт, нам не надо решать, применять АВД или нет — он просто должен быть. Без вариантов. И если ваш дизайн не адаптивный, то, как сказал Энди Кларк (ANDY СLARKE):

«Это уже не веб-дизайн, а что-то другое. Если вы не учитываете в своей работе врожденное непостоянство веба, то вы не веб-дизайнер, а кто-то другой. Веб-дизайн — это адаптивный дизайн, а адаптивный веб-дизайн — это веб-дизайн, и никак иначе.»

Круг «АВД — это тренд»

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

Как правило, критики АВД опираются на техническую сторону вопроса, а также на практичность применения такого подхода с точки зрения бизнеса. Это, в свою очередь, заставляет переосмыслить многие вещи, такие как платформа для содержания и затраты на редизайн. Критики также аргументируют тем, что технологии типа @media-queries и javascript до сих пор не поддерживаются браузерами во многих мобильных устройствах.

Несмотря на то, что рассматриваемый метод (философия) еще очень молод, эта группа не слишком ему рада.

Дизайнерский взгляд

Большинство обсуждений АВД уделяет слишком большое внимание техническим аспектам. Это не адаптивная веб-разработка, это — адаптивный веб-дизайн. Смотреть сайт в превосходном качестве на любом экране звучит красиво. Самый простой дизайнерский ответ на вопрос о пользе АВД звучит так: «все зависит от …». Очевидно, что это беспроигрышный вариант. Поэтому далее я попытаюсь сформулировать свое мнение, дав другой ответ.

«Но что значит быть по-настоящему „адаптивным“? Я считаю, что это обязывает понимать человека по другую сторону экрана и, самое главное, контекст, в котором он находится.»
— Джеймс Пирс (JAMES PEARCE)

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

Каждое устройство имеет форм-фактор и относится к определенному классу устройств [2]. Например, смотря телевизор, вы можете откинуться назад и с расстояния в 10 футов взаимодействовать с ним, используя пульт управления.

«Хотя и существует возможность использовать всего один интерфейс для работы с более, чем одним классом устройств, разработка такого интерфейса обычно приводит к существенным компромиссам или рахитичному опыту взаимодействия, который не позволяет воспользоваться преимуществами, делающими каждый из классов превосходным (или наоборот: к богатым функциональным возможностям, которые не загружаются или ломаются на слабых устройствах).»
— Люк Вроблевски (LUKE WROBLEWSKI)

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

  • 93% людей используют свои смартфоны дома;
  • 62% людей используют свои смартфоны для просмотра видео-каналов;
  • 39% людей используют свои смартфоны, когда сидят на толчке.

IPad рассматривается скорее как «портативное», чем «мобильное» устройство, поскольку люди не всегда берут его с собой. И при этом, в большинстве случаев люди ожидают полную функциональность, а не урезанную или модифицированную версию [4].

«Больше 10 лет создания веб-сайтов потребовалось сообществу разработчиков на то, чтобы понять, что конкретные знания о наших посетителях действительно очень важны. Почему сегодня, когда некоторые браузеры помещаются в нашем кармане и имеют сенсорные экраны вместо курсора, мы решили, что больше не нуждаемся в хорошей информации о пользователях?»
— Мэтт Генри (MATT HENRY)

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

Панацеи нет

Проблема, которую мы пытаемся решить, очень сложная. Я знаю, что многие люди ведут разработку «от содержания». И это правильно, содержание — во главе всего. Если содержание не имеет значения, то и то, как вы будете делать сайт, тоже не важно. При этом не все так однозначно, поскольку здесь присутствует множество других факторов. Например:

  • Является ли продукт/содержание желанным для потребителя?
  • Готов ли заказчик, и есть ли возможность донести то видение, которое мы проектируем?
  • Готовы ли клиенты попробовать наш новый продукт/услугу вместо текущего решения?

Изображение взято с сайта Yiibu.

Иногда мне кажется, что мы (наша отрасль) очень похожи на определенный тип правительства, которое совершенно оторвано от жизни обычных людей. Самый широкий канал интернета и последняя версия браузера — далеко не для каждого это находится в списке жизненных приоритетов. Мы же, как правило, предпочитаем разрабатывать что-либо для новых устройств, таких как iPhone, потому что там мы действительно можем использовать интересные штуки-дрюки и изучать самые современные технологии. Если даже iPhone имеет слабое проникновение в секторе мобильных устройств [5].

Большинству людей вне нашей отрасли не нужно то дерьмо, которое мы создаем. Просто дайте им самый удобный способ перевести деньги в Farmville (популярная игра в социальной сети Facebook, аналог «Фермы» в Вконтакте — прим. переводчика), чтобы они смогли вырастить еще больше овощей. Я верю в человеческий фактор, и понимание контекста, в котором люди получают интересующую их информацию, — вот что может быть постоянной задачей. Мне кажется, что никогда не будет найдена панацея в дизайне для людей. Мы изучаем то, каким образом люди «думают», гораздо дольше существования интернета. И мы знаем достаточно, чтобы понять, что мы не знаем ни хера.

«Дизайн — это размышление о содержании и его подаче. Фокусируйтесь на картине в целом. Макет — это еще не дизайн.»
— Люк Вроблевски (LUKE WROBLEWSKI)

Противники говорят, что АВД — это тренд, который скоро умрет. С другой стороны медали находятся сторонники, утверждающие, что нашли Святой Грааль. Каждый надеется на очередного спасителя, который избавит нас от всех проблем. Я вижу одно решение: настойчивость и эволюция с целью создания отличного опыта взаимодействия.

[1] Mobile-first Responsive Web Design, Брэд Фрост (BRAD FROST)
[2] Networked Consumer Device Platforms, Люк Вроблевски (LUKE WROBLEWSKI)
[3] The Myth of Mobile Context
[4] Five Lessons From a Year of Tablet Research
[5] Rethinking the Mobile Web

Стандартный
Статьи

П.И. Браславский, Е.А. Вовк, М.Ю. Маслов. «Фасетная организация интернет-каталога и автоматическая жанровая классификация документов»

Из аннотации к статье:

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

Читать полную версию онлайн

Стандартный
Статьи

«Изящная деградация» vs. «постепенное улучшение»

Автор статьи: Кристиан Хейльманн (Christian Heilmann)
Оригинал: http://dev.opera.com/articles/view/graceful-degradation-progressive-enhance/ (3 февраля 2009)

Вступление

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

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

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

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

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

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

«Мобильность в мобильном» — движение в постоянно изменяющемся окружении

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

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

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

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

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

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

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

«Изящная деградация» и «постепенное улучшение» под микроскопом

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

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

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

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

Пример

Давайте рассмотрим пример, иллюстрирующий использование обоих методов: и метода «изящная деградация», и метода «постепенное улучшение».

Ссылка «Распечатать эту страницу»

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

Проблема с ссылками «Распечатать эту страницу» заключается в том, что в HTML нет никакой возможности связать их с функцией печати, имеющейся в браузере — для этого необходимо использовать JavaScript. В JavaScript это делается очень просто. Объект браузера window имеет метод print(), который может быть вызван для старта процедуры печати.

Пожалуй, наиболее распространенный способ сделать это заключается в использовании псевдо-протокола javascript::

<p id="printthis">
  <a href="javascript:window.print()">Распечатать эту
    страницу</a>
</p>

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

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

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

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

В нашем случае это может выглядеть так:

<p id="printthis">
  <a href="javascript:window.print()">Распечатать эту
    страницу</a>
</p>
<noscript>
  <p>
    Для печати страницы необходима поддержка JavaScript.
    Пожалуйста, включите ее в вашем браузере.
  </p>
</noscript>

Это и считается изящной деградацией. Мы объяснили пользователю, что что-то не так и как это исправить. Однако, это предполагает, что посетитель вашего сайта:

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

Если попробовать перефразировать, то получится немного лучше:

<p id="printthis">
  <a href="javascript:window.print()">Распечатать эту
    страницу</a>
</p>
<noscript>
  <p>
    Для печати копии вашего подтверждения
    кликните иконку “Печать” в вашем браузере
    или выберите пункт “Печать” в меню “Файл”.
  </p>
</noscript>

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

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

Кнопки предназначены для поддержки скриптовой функциональности уже по определению. В спецификации W3C сказано:

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

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

<p id="printthis">Спасибо за ваш заказ.
Пожалуйста, распечатайте эту страницу,
чтобы не забыть его параметры.</p>

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

<p id="printthis">Спасибо за ваш заказ.
Пожалуйста, распечатайте эту страницу,
чтобы не забыть его параметры.</p>
<script type="text/javascript">
(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Распечатать');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();
</script>

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

  • Оборачивая всю функциональность в анонимную функцию и незамедлительно ее выполняя (это то, что делает конструкция (function(){})()), мы оставляем глобальную область видимости чистой.
  • Мы тестируем браузер на поддержку DOM и пытаемся получить элемент, в который хотим вложить кнопку.
  • Далее мы проверяем, существует ли этот элемент и имеет ли браузер объект window с методом print (путем тестирования этого свойства на тип «функция»).
  • В случае, когда оба условия выполняются, мы создаем новую кнопку и назначаем для нее window.print() в качестве обработчика на клик мышью.
  • Последний шаг — вставляем кнопку внутрь тега параграфа.

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

Когда и что использовать

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

Когда мой ноутбук не может найти беспроводное подключение, я использую для выхода в сеть смартфон Blackberry и очень расстраиваюсь, если веб-сайты сообщают мне о том, что им нужен JavaScript и что я должен его включить. Ведь я не могу это сделать! Но, тем не менее, я — полноправный пользователь ваших продуктов. Особенно тогда, когда плачу кучу денег за GPS- и EDGE-доступ к вашим сервисам.

Однако, метод «изящная деградация» жизнеспособен в ситуации, если:

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

Во всех других случаях метод «постепенное улучшение» сделает вас и ваших пользователей счастливее:

  • Независимость от окружения и возможность предоставлять продукт, который всегда работает.
  • Когда выходит новый браузер, или когда какое-либо расширение для браузера становится широко распространенным, вы можете подняться на более высокий уровень, не затрагивая основное решение (метод «изящная деградация» может потребовать от вас изменения основного решения).
  • Вы позволяете технологии быть тем, для чего она создана — реальной помощью в более быстром достижении целей, а не быть причиной использовать ее же только потому, что она «должна быть».
  • Если вам нужно добавить новые функции, вы можете это сделать после того, как на определенном этапе проверите их поддержку. Или вы можете добавить их на самый базовый уровень функциональности, а довести до совершенства в более сложном окружении. В любом случае поддержка решения осуществляется в одной точке, а не в двух разных местах. Поддержание одного продукта в актуальном состоянии за счет метода «постепенное улучшение» требует меньше усилий, чем поддержка двух различных версий.

Заключение

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

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

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

Вопросы для самотренировки

  1. В статье рассматриваются ссылки на печать как пример, для реализации которого можно использовать оба метода. Какие другие примеры вы можете привести?
  2. Допустим, что вы хотите использовать JavaScript, чтобы перед отправкой формы проверить, содержит ли поле ввода адрес электронной почты. Чем бы характеризовалась разница в методах для этого случая? Какие сопутствующие проблемы необходимо принять во внимание?
  3. Допустим, что вам нужно отобразить географическую карту и при этом использовать метод «постепенное улучшение». Какой должна быть та базовая функциональность, с которой вы начнете?
  4. Представим себе, что у вас есть интерфейс, состоящий из формы с двумя выпадающими списками. Выбор одного из вариантов в первом списке изменяет список вариантов во втором списке. Что может выступать в роли запасного варианта решения при использования таких типов элементов управления? Какие проблемы при этом могут возникнуть?

Об авторе

Крис Хейльманн занимается веб-разработкой более 10 лет, до этого пробовал себя в радио-журналистике. Работал в английском подразделении компании Yahoo! в качестве тренера и ведущего разработчика, контролировал качество клиентского кода для проектов с аудиторией из Европы и Азии.

Крис ведет блог «Wait till i come», а также присутствует во множестве социальных сетей, таких как «codepo8».

Picture of the article author Chris Heilmann
Photo credit: Bluesmoon

Стандартный