В последнее время появилась целая куча способов создания отзывчивых картинок (responsive images) — иными словами, появились технические средства, обеспечивающие подстановку правильной иллюстрации в зависимости от ряда условий (например, от размеров экрана и скорости доступа к Интернету у читателя). Все эти средства делают своё дело несколько по-разному; чтобы сопоставить их, мы с Кристофером Шмиттом составили электронную таблицу их возможностей и требований.

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

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

Сколько прежнего контента у меня есть?


На самом деле этот вопрос означает «есть ли у меня такой прежний контент, который обновить не выйдет?». Например, на сайте CSS-Tricks у меня более тысячи страниц, а работаю над ними один я:

[статистика прежнего контента]

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

Единственное известное мне средство, которое для работы вовсе не требует изменений в разметке — это Adaptive Images. Работает оно, перенаправляя запросы к изображениям через PHP-скрипт, который разумно подбирает (а при необходимости и создаёт) иллюстрации того размера, который подходит под ширину экрана у читателя.

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

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

Подходит ли мне специальная разметка?


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

<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png">

Этот приём создаёт ясный, валидный, семантически корректный код, однако он также приводит к необходимости добавлять эти атрибуты в каждый элемент <img> на сайте, что может и не быть возможным для сайтов с грудами прежнего контента.

Если вы приходите к мысли о том, что специальная разметка (или специализированный стиль CSS) для вас не годится, тогда остаётся только Adaptive Images. Ведь даже для Sencha.IO потребуется поместить префикс в атрибуте src, и это потребует обработки прежнего контента.

Необходим ли мне семантический код?


Некоторые технические приёмы создания отзывчивых картинок подразумевают такую разметку, которая в строгом смысле не является семантическою. В конце концов, для изображения есть только один способ быть семантическим: его атрибут src должен указывать на реальное изображение, а атрибут alt должен содержать текст, описывающий это изображение. Что хорошо подытожил Брэд Фрост:

[скриншот диалога во Твиттере]

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

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

Если для вас важна семантичность, то взгляните на вышеупомянутый Adaptive Images или же на HiSRC — плагин для jQuery, созданный Кристофером Шмиттом и допускающий употребление с семантическим атрибутом src.

Некоторые другие средства используют элемент <noscript>, в котором помещают подстраховочный код <img> на тот случай, если JavaScript отключён или недоступен. Предоставляю вам самим решить, семантический это код или нет.

Нужна ли мне валидность кода?


Под валидностью здесь понимается способность кода пройти проверку W3C Markup Validation Service. Это средство проверки помогает вам найти проблемный код, помогает создавать разметку лучше. Но код не становится хуже просто потому, что он не проходит проверку: если невалидный код прекрасно работает во всех браузерах, то его валидность не должна заботить ни вас, ни кого-нибудь другого.

Однако же, если валидность вам нужна (например, если заказчик непременно требует её от вас, угрожая отказом от оплаты за работу), то некоторые средства обеспечения отзывчивых картинок вы использовать не сможете. Например, picturefill использует элемент <picture>, который может со временем оказаться стандартизирован, но сейчас это не так, так что код получается невалидным. Кроме того, по стандарту требуется, чтобы элемент <img> имел атрибут src — так что отказ от этого атрибута с намерением избежать вышеупомянутой проблемы двойного запроса картинок также приводит к невалидному коду.

Если валидность кода является для вас непременным требованием, то я рекомендую Adaptive Images, или HiSRC, или Responsive Enhance. Все эти средства используют простой и валидный синтаксис <img>, который содержит атрибут src.

Нужен ли мне тонкий контроль над изображениями?


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

[три иллюстрации]
Левая из этих трёх картинок предназначена для мобильников и первоначально указывается в src. Средняя, несколько большего размера, может использоваться планшетами. Справа — наиболее крупная из иллюстраций. (Вот их первоисточник.)

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

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

<picture alt="description">
  <source src="small.jpg">
  <source src="medium.jpg" media="(min-width: 400px)">
  <source src="large.jpg" media="(min-width: 800px)">
</picture>

Далее ими занимается JavaScript.

Нужно ли мне наличие JavaScript?


Большинство средств для создания отзычивых картинок именно джаваскриптом совершает свои фокусы. Некоторые из них — очень немного (только чтоб cookie поставить), но всё равно джаваскриптом. Для нескольких средств вам придётся поместить <img> внутри элемента <noscript> на тот случай, когда у читателя JavaScript отключён. Если такой подход вам не нравится, но если вам притом надобно быть уверенными, что картинки и без джаваскрипта заработают, то вам лучше всего будет положиться на Sencha.IO. Этот сервис построен на идентификации устройст по заголовку «User-Agent» и передаёт соответственно уменьшенное изображение. Так что вы сошлётеся на наибольшую (в разумных пределах) версию изображения из имеющихся у вас, а Sencha его уменьшит и передаст читателю уменьшенную версию при необходимости (увеличением же, по понятным причинам, не занимается).

Как насчёт зависимости от джаваскриптовых библиотек?


И HiSRC, и rwdImages работают на jQuery. Если в вашем проекте используется другая библиотека, то эти средства для вас, возможно, не подойдут. (Но вы можете портировать их, а затем открыть исходный код!) А если вы не пользуетеся никакою библиотекою, ну, тогда пора бы ужé, наверное — но сейчас не будем об этом.

Нужны ли мне серверные скрипты?


Некоторые из обсуждаемых нами средств зависят не только от джаваскриптов. Adaptive Images полагается в основном на .htaccess да на PHP. Ну а .htaccess предполагает сервер Apache. И хотя, конечно, все мы знаем и любим PHP (кхе-гхм), многие вебсайты работают на технологиях вроде Ruby или Python.

Responsive Images (первоначальная версия от Filament Group) также пользуется .htaccess. Так что если в качестве сервера у вас нечто вроде Nginx, то придётся либо отказаться от этого технического средства, либо портировать код .htaccess на подобный ему, но отличающийся синтаксис конфигурации Nginx.

Нужно ли мне проверять скорость Интернета у читателя?


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

Два нынешних инструмента обеспечения отзывчивости картинок проверяют скорость Интернета, когда принимают решения: Foresight.js и HiSRC (они применяют один и тот же приём из Foresight.js). Работает это через скачивание тестового файла с измерением времени скачивания (пороговое значение настраивается в конфигурации). Сам тест несколько подтормаживает загрузку страницы, но, теоретически, экономия на размере изображений, скачиваемых в зависимости от скорости, стóит того.

Могу ли я полагаться на сервисы других лиц?


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

Конечно, вы можете думать так: «Клёво, приёмы Sencha.IO превосходны, но необходимость полагаться на их сервер вызывает беспокойство — хотел бы я запустить нечто подобное у себя на сервере». Если вы и впрямь хотите этого, тогда есть общедоступная база данных WURFL, и есть средство Server Side Responsive Images для локальной работы с нею.

Имеются также сервисы наподобие Device Atlas Cloud, занимающиеся распознаванием устройств. Они также создают зависимость от себя. Сомнений нет: их цель в том, чтобы всё время оставаться в онлайне и работать быстро, но призадумайтеся поосторожнее о том, как и от кого вы желаете зависеть в своём деле.

Есть ли специальная CMS со специальными возможностями?


Предположим, что проект ваш основан на WordPress. А в WordPress есть ведь встроенный загрузчик иллюстраций. Когда вы им загружаете иллюстрацию на сайт, то он может создать несколько уменьшенных версий изображения. Это круто, это мощно, и этим можно (нужно) воспользоваться. Keir Whitaker обсуждает использование этой возможности в своей статье «Automatic Responsive Images in WordPress».

Приём этот, конечно, годится не только для WordPress. Я уверен, что такое же средство существует (или может быть прикручено) к любой CMS.

Могу ли я дожидаться будущего?


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

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

Возможно, станем переключать src у картинок посредством CSS-свойства content, как предложил Nicolas Gallagher. Возможно, стандартизируют элемент <picture>. Возможно, будет атрибут srclist в HTML или свойство src в CSS. Возможно, будет префикс.

См. также