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

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

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

Имеется ли у меня уже существующий контент?

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

Даааа… Я точно не собираюсь идти и менять каждый тег <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 содержится его описание.  Брэд Фрост весьма емко высказался про это:

Перевод: Matt Stow: «@brad_frost IMO, фактические пиксели изображения не должны иметь значения. Пользователи все равно увидят картинку, а программы для чтения с экрана позволят услышать ее.»  Brad_Frost: «@stowball К сожалению, всё не так просто. Изображение лошади должно быть именно изображением лошади, иначе это не изображение лошади».

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

Так почему же тогда некоторые техники это используют? Потому что, если у вас есть <img>, и src указывает на изображение лошади, то это значит, что данное изображение начнет загружаться сразу же, как браузер до него доберется. И избежать этого не получится. Даже если вы супер быстро заменили src на более удобоваримый вариант, теперь загружаться будут два изображения вместо одного, что в итоге приводит к потерям производительности, а не наоборот. Вы можете придти к решению, что это вполне допустимо (к примеру, на настольных компьютерах, как правило, скорость выше). Обычно при использовании этой техники, в src указывается самое маленькое изображение.

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

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

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

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

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

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

Нужна ли возможность манипулирования изображениями?

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

Слева исходный src, для мобильных устройств. В середине немного большее изображение, которое может быть использовано на планшетах, к примеру. Справа самое большое изображение. (credit)

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

Если эта возможность важна для вашего проекта, вам нужна техника, которая позволяет задать, какое именно изображение выдавать в каждом конкретном случае. И 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?

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

А что насчет зависимости от библиотек JavaScript?

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

Волнует ли меня серверная часть?

Не все из обсуждаемых техник зависят исключительно от JavaScript. 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 database и Server Side Responsive Images technique, которые делают то же самое локально.

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

А может используется CMS с особыми возможностями?

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

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

Могу ли я подождать?

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

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

Например, это может быть подстановка ссылок на изображение в src через CSS content, как предлагает Николя Галлахер (Nicolas Gallagher). Это может быть, элемент <picture>. Или, может, атрибут srclist в HTML или свойство src в CSS. Или префикс.

Источник:  css-live.ru