29 августа 2012: дата, которая войдет в историю, так как именно в этот день мы получили официальную спецификацию для адаптивных изображений. Пару недель назад W3C опубликовала черновик редакторов для адаптивных изображений, который был написан Мэтью Маркесом (Mathew Marquis) и Адрианом Бэйтманом (Adrian Bateman).
После года обсуждений в сообществе разработчиков о наилучшем способе применения адаптивных изображений, W3C, наконец, облегчили всем задачу, попросив Мэта Маркеса и Filament Group написать спецификацию. В данной статье мы рассмотрим события, которые привели к такому решению, цели спецификации, а также изучим некоторые проблемы, которые все еще нужно решить.
Немного истории
Если вы не в курсе всех дебатов по поводу адаптивных изображений, то давайте немного ознакомимся с темой.
Многие люди (включая и наш ресурс) публиковали статьи на эту тему.
* Был сделан запрос на HTML-решение для адаптивных изображений к WHATWG в июле 2011 года.
* Тема исчезла до ноября 2011 года.
* Другие люди начали исследовать тему, и она стала популярной, даже без ответа от W3C/WHATWG.
* В феврале 2012 года W3C сформировала группу для дальнейшего обсуждения темы.
* В февраля 2012 года WHATWG обсудили другой подход, при помощи атрибута srcset, смутив всех, так как он сильно расходился с предложенным им вариантом. В мае 2012 это предложение стало публичным, что означало продолжение дебатов.
* После дальнейших обсуждений между W3C и WHATWG, в августе 2012 года все, наконец, стало ясно, и W3C предложили элемент «picture» включая srcset.

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

Сверху: экран iPad2 при 132ppi разрешения. Можно видеть все пиксели.
Снизу: экран высокого разрешения на iPad3 выглядит гораздо более плавно.
Цель адаптивных изображений
Если вы все еще не понимаете, для чего нам нужна спецификация для адаптивных изображений, то давайте рассмотрим, что это может нам дать:
* Реализовать соответствие различной ширине/высоте пикселя в HTML.
* Реализовать соответствие различной плотности пикселей (высокое разрешение/низкое разрешение).
* Позволяет пользователям увеличивать и уменьшать изображения (например, посресдством лайтбокса).
* Предоставлять браузерам пользователей информацию о том, какое изображение больше всего подходит клиенту. Это производится при помощи media queries (пока что не доступно).
* Предотвратить разломы в верстке и стилях.
* Предоставлять полноценное решение на клиентской стороне, которое включает в себя JS, но не требует самой библиотеки.
* Предоставлять различные вариации одного и того же изображения, в зависимости от размера и свойств окна просмотра (например, когда нужно отобразить черно-белое изображение для читателей E-ink).

Как работают экраны высокого разрешения. Слева 4-хпиксельное устройство при стандартном разрешении; Справа 16-пиксельное устройство, которое отображает изображение того же размера.
Как принять адаптивные изображения
Текущая спецификация позволяет вам сделать две вещи:
* Указывать различные разрешения одного и того же изображения при помощи атрибута srcset. Вам не нужно будет беспокоиться о media queries, и только лишь предоставить изображения 1х (нормального разрешения), 1.5х (более высокого разрешения) и 2х (для разрешения Retina). Клиентское приложение сделает все остальное.
* Использует различные изображения для разных разрешений. Вы указываете media queries, определяете разные разрешения или различные типы устройств, и подготавливаете определенные изображения для отдельных пользователей. Более детальная разработка, но требует больше усилий.
Элемент «picture» будет иметь следующий синтаксис:
<picture>
<source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
<source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
<source srcset="small-1.jpg 1x, small-2.jpg 2x">
<img src="small-1.jpg" alt="my alt-text" width="200" height="100">
</picture>
Это обычный пример того, как можно использовать адаптивные изображения. Как видно, новый элемент обратно-совместимый ввиду того факта, что вы можете интегрировать обычный элемент «img» в элемент «picture». Это означает, что у вас всегда будет откат для более старых версий браузеров, которые не поддерживают элемент «picture» и, более того, это позволяет нам использовать элемент «picture» уже сейчас. Тем не менее, мы бы не рекомендовали вам использовать синтаксис, указанный в первом черновом варианте.
Вы можете комбинировать srcset с media queries для того, чтобы указывать конкретные размеры экранов, и позволить пользовательским приложениям решить, пользователь получит изображения высокого или низкого разрешения. Это делает синтаксис невероятно гибким с точки зрения определения изображения, и очень близким к идеальному решению, касательно адаптивных изображений.

Размеры файлов, которые вам понадобятся при создании изображения для экранов с различной плотностью пикселей. Изображение должно отображаться в том же размере, независимо от того, на каком устройстве оно просматривается: увеличение плотности приводит лишь к повышению резкости изображения.
Требования к браузерам
Есть несколько вещей, необходимых для того, чтобы элемент «picture» работал. Они все относятся лишь к требованиям к браузерами, поэтому давайте отметим ключевые аспекты:
* Пользовательское приложение должно извлекать соответствующий данные в рамках одного запроса.
* Пользовательское приложение должно иметь возможность переписывать значения разработчика настройками пользователя (например, когда разработчик говорит скачивать изображение высокого разрешения, но пользователь выставил настройки на маленькое разрешение, приложение должно предоставлять ему изображения низкого разрешения).
Проблемы, на данный момент нерешенные
Так как первый черновой вариант вышел всего несколько недель назад, обсуждения все еще продолжаются, как на WHATWG, так и на W3C. К счастью, большинство главных проблем уже решено, как кажется. Большинство оставшихся нерешенными проблем очень тривиальны, поэтому нам не стоит здесь подробно их разбирать. Тем не менее, есть небольшое исключение:
Нам до сих пор не очень ясно, как определить альтернативный контент для элемента «picture». В рассылках одно решение заключается в текстовом откате внутри элемента (в виде дочерних элементов). Другое же заключается в простом использовании атрибута alt, как для элемента «picture», так и для элемента «source». Так как это может привести к серьезным проблемам с точки зрения доступности и удобства пользования, стоит подождать дальнейших действий и решений.