Сценарии использования и требования по стандартизации отзывчивых изображений.

Опубликовано: 21 февраля 2014      Перевод:

Записка W3C рабочей группы от 05 ноября 2013 года.

Данная версия:
http://www.w3.org/TR/2013/NOTE-respimg-usecases-20131105/
Последняя опубликованная версия:
http://www.w3.org/TR/respimg-usecases/
Последняя редакторская версия:
http://usecases.responsiveimages.org/
Предыдущая версия:
http://www.w3.org/TR/2013/WD-respimg-usecases-20130226/
Редакторы:
Marcos Cáceres, Mozilla
Mat Marquis
Yoav Weiss
David Newton
История версии:
Commit History
Github commits on Twitter
Подключиться к проекту можно:
Join the Responsive Images Community Group
Список рассылки
IRC:#respimg on W3C's IRC
Twitter
Github

Обзор.

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

Нашли ошибку, опечатку или спорный вопрос? Будем рады вашему сообщению или отправленному на github файлу об ошибке.

Статус данного документа.

В этом параграфе разъясняется статус данного документа на момент его публикации. Он может быть переопределен другими документами. Список текущих публикаций W3C консорциума, а также последнюю редакцию этого технического сообщения вы можете найти в каталоге технических сообщений W3C на http://www.w3.org/TR/.

Этот документ был опубликован рабочей группой по HTML в качестве Записки рабочей группы. Если вы желаете оставить свои комментарии касательно данного документа, отправляйте их, пожалуйста, по адресу public-respimg@w3.org (подписаться, архивы). Приветствуются любые комментарии.

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

В ходе разработки данного документа рабочая группа руководствовалась Патентной политикой W3C от 5/02/2004. W3C консорциумом также ведется общедоступный реестр раскрытий сущности любого патента, созданный в связи с завершением определенных этапов деятельности данной группы. Та же страница содержит инструкции по внесению раскрывающей сущность патента информации. Личности, действительно обладающие претендующей на патент информацией, которая по мнению ее владельца имеет на это Существенное(ые) основание(я), должны раскрыть эту информацию в соответствии с требованиями, изложенными в разделе 6 Патентной политики W3C.

1. Введение.

В HTML условия окружения пользовательского агента выражаются главным образом посредством CSS медиа характеристик (таких к примеру, как pixel-density, orientation, max-width и т.д.) и CSS медиа типов (таких как print, screen и т.п.). Отзывчивое изображение — это изображение, которое адаптируется в ответ на изменения условий окружения: адаптация может выполняться, но отнюдь не ограничиваться изменением размерностей, способов кадрирования и даже источника изображения.

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

Более того, в связи с ростом количества и разновидностей дисплеев высокого разрешения (как мобильных, так и стационарных), веб-разработчики вынуждены были создать методики, которые позволяют предоставлять изображения, отвечающие условиям окружения браузера. Вы можете ознакомиться со списком, представленным в статье Крисса Койера «Какое из решений отзывчивых изображений необходимо использовать?», в котором перечислены применяемые в 2012 году технологии. Эти методы обладают рядом обсуждаемых далее в документе ограничений, которые и выступили в роли мотиваторов к стандартизации подобных методик с привлечением таких организаций как W3C и WHATWG.

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

1.1 Предложенные решения.

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

Атрибут 'srcset'
Позволяет авторам определять различные источники изображения и хинты («подсказки»), содействующие пользовательскому агенту при выборе наиболее подходящего для отображения изображения. Обладая предоставленным набором источников изображения, пользовательский агент в ходе оптимизации пользовательских возможностей получает возможность выбора между указанным в декларации элементом и переопределяющим его альтернативным вариантом, основываясь на таких критериях как плотность дисплея, тип соединения, предпочтения пользователя и им подобных.
Элемент 'picture'
Построенная на функционале srcset, эта спецификация представляет собой декларативное решение, которое предусматривает группировку нескольких версий изображения, основанных на различных показателях (таких как формат, разрешение, ориентация и т.д.). Этот подход позволяет пользовательскому агенту выбрать оптимальный, отвечающий условиям окружения вариант изображения, который будет представлен конечному пользователю, обеспечивая к тому же возможность «художественного редактирования» изображений.
HTTP Client Hints
Определяет набор заголовков HTTP запроса, которые позволяют браузеру указывать список обусловленных конфигурацией устройства и пользовательского агента предпочтений. Серверы в последствии могут использовать эти «подсказки клиента» ("client hints") с целью облегчения достижения договоренности в вопросе выбора предоставляемого контента, и в идеальном случае это приводит к тому, что доставляемый контент наилучшим образом отвечает условиям окружения клиента с учетом требований запрашиваемого ресурса.
Предложение RespImg синтаксиса
RespImg синтаксисом вводится ряд новых src-n атрибутов для элемента img, допускающих использование небольшого набора микросинтаксисов, в функционале которых отображены требования таких сценариев использования как выбор на основе вьюпорта, выбор на основе пиксельного коэффициента устройства и художественное редактирование, описанных в этом документе. Предложением требуется, чтобы данный синтакис разрабатывался с учетом проблем реализации, выявленных в ходе работы над проектом элемента picture.

2. Ограничения существующих методик.

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

Зависимость от семантически нейтральных элементов и применения CSS фона.
Объемные изображения приводят к неоправданному увеличению времени, которое требуется на их загрузку и обработку, создавая тем самым неудобства для пользователя. Для того чтобы обойти эту проблему веб-разработчики указывают несколько источников одного изображения, содержащих его варианты различного разрешения и затем извлекают изображение с нужными размерами, соответствующими величине целевого вьюпорта. По причине того, что разработчики не располагают специальными средствами разметки, предназначенными для этих нужд, им приходится полагаться на семантически нейтральные элементы, фоновые CSS изображения и библиотеки JavaScript. Другими словами, разработчики просто вынуждены умышленно нарушать требования, предъявляемые авторам HTML стандартом.
Шунтирование работы сканера предварительной загрузки.
Вынужденное использование семантически нейтральных элементов (подобных div и span) вместо семантически значимых элементов, таких как img приводит к тому, что браузеры не выполняют загрузку изображений до тех пор, пока не будет сформировано (хотя бы частично) DOM дерево и выполнены скрипты. Это напрямую препятствует эффективной работе браузерных движков, функционал которых совершенствовался годами с целью оптимизации процесса загрузки ресурсов (это касается модулей, подобных HTMLPreloadScanner в WebKit). Беспричинное шунтирование таких вещей как сканер предварительной загрузки может оказать умеренное воздействие на производительность в процессе загрузки документов. В качестве примера вы можете ознакомиться с небольшим исследованием, проведенным Тони Гентилкором в его публикации «The WebKit PreloadScanner», которое наглядно показывает, что размер ущерба, наносимого производительности, может достигать 20% при заблокированном модуле PreloadScanner в WebKit. Более свежие тесты производительности дали похожие результаты. Детальная информация по этому вопросу содержится в статье Энди Дэвиса «Как модуль браузера Pre-loader ускоряет загрузку страниц».
Зависимость от скриптов и обработки серверной стороной.
Существующие методики основаны на JavaScript или на серверном решении (либо на обеих), что является причиной усложнения процесса разработки из-за использования избыточности HTTP запросов. Более того, JavaScript варианты недоступны для пользователей, отключивших поддержку JavaScript.

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

3. Прецеденты.

Приведенные ниже прецеденты представляют часто встречаемые в «реальности» сценарии использования.

3.1 Выбор на основе разрешения.

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

Выбор на основе разрешения.

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

3.2 Выбор на основе вьюпорта.

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

Так, допустим, изображение шириной в 1000px, используемое в качестве фона страницы, целесообразно рассматривать как полномасштабное 1x изображение, но при использовании его в тех же целях на экранах с шириной в 320px оно будет слишком большим. На экранах меньших размеров данное изображение скорее всего будет в два, а то и в три раза превышать доступное пространство, то есть его можно классифицировать как 2x или 3x изображение соответственно. Другими словами одно и то же изображение вполне подходит для использования при различных размерах вьюпорта, однако, с разными эффективными разрешениями.

Выбор на основе вьюпорта.

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

3.3 Выбор на основе пиксельного коэффециента устройства.

С целью снижения видимых деффектов при отображении изображений (то есть для того, чтобы изображения выглядили «четко»), на устройствах с различной плотностью дисплеев должны использоваться изображения с разным значением минимального разрешения. Таким образом, чем выше пиксельная плотность (device-pixel-ratio — пиксельный коэффициент устройства), тем больше пикселей должно содержать изображение чтобы выглядеть хорошо. Это также касается и пиктограмм, когда для использования при различных dpr могут понадобиться совершенно разные изображения (см. статью Невена Мргана / Neven Mrgan "All the sizes of iOS app icons" / «Все размеры пиктограмм iOS приложений»).

Выбор на основе dpr.

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

3.4 Художественное редактирование.

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

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

Этот подход демонстрируется в следующем примере:

Художественное редактирование.

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

Схожий прецедент имеет место, когда исходя из ориентации определяются следующие параметры изображения:

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

Взять, к примеру, сайт Nokia Lumia, при открытии находящегося там описания браузера Meego на широком дисплее Nokia Lumia изображена в горизонтальном положении, а при сужении экрана ее изображение меняется на вертикальное с обрезкой. Дизайнеры сайта Брайан и Стефани Ригер объясняют это тем, что при открытии этого документа на широком дисплее расположенный горизонтально телефон позволяет наилучшим образом представить пользователю браузер, но на малых экранах благодаря смене положения устройства на вертикальное, посетитель сайта все еще в состоянии достаточно детально рассмотреть представленные на изображении возможности браузера.

Изображение 5.
Видео, демонстрирующее использование «художественного редактирования» на сайте Meego корпорации Nokia.

3.5 Контрольные точки дизайна.

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

Пример 1

@media screen and (max-width: 16em) { … }
@media screen and (max-width: 32em) { … }
@media screen and (max-width: 41em) { … }

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

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

3.6 Согласование с медиа характеристиками и медиа типами.

Согласно приведенной в Википедии статье «dpi — Точек на дюйм»:

«Разрешающая способность печати струйного принтера … как правило, находится в диапазоне от 300 до 600 dpi. Лазерный принтер … печатает с точностью от 600 до 1800 dpi.»

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

Распечатка пиктограммы с потерей качества.

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

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

Тем не менее, отображение цветных изображений на монохромных устройствах (на бумаге и дисплеях технологии e-link) может быть проблематичным, поскольку разные цвета с идентичной степенью яркости невозможно отличить при отображении на монохромных устройствах. Данная проблема продемонстрирована в следующем примере, содержащем круговую диаграмму, сектора которой практически невозможно ассоциировать с соответствующими им ярлыками. Эта ситуация является широко известной проблемой веб-дотупности, описанной в WCAG 2.0. Решение, которое предоставит разработчикам возможность выявлять такие случаи по медиа типам смогло бы потенциально повысить уровень доступности графического контента.

Цветная и монохромная диаграммы.

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

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

В итоге, CSS рабочая группа W3C консорциума посредством спецификации "CSS Media Queries" («CSS Медиа запросы») продолжила введение в Web платформу новых медиа характеристик. В качестве новых медиа-направленных компонентов следующего уровня спецификации "CSS Media Queries level 4" («CSS модуль — Медиа запросы — Уровень 4») можно назвать: script, pointer, hover и luminosity. Отсутствие декларативного механизма, позволяющего связывать графический контент с существующими медиа характеристиками говорит о том, что разработчики не могут применять их не прибегая к использованию вышеупомянутых ограниченных технологий.

3.7 Относительные единицы.

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

Если размеры художественно отредактированных изображений устанавливаются без использования относительных единиц, то при необычном дефолтном размере шрифта (примером может быть Amazon’s Kindle с 20-пиксельным дефолтным размером шрифта вместо 16px) это может привести либо к нарушению структуры шаблона, либо к искажению самих изображений.

3.8 Форматы изображений.

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

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

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

3.9 Контроль источников изображений пользователем.

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

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

Некоторые браузеры уже принимают необходимые меры в подобных ситуациях. Opera Mini, к примеру, предоставляет своим пользователям возможность выбора качества изображений (однако, это достигается путем сжатия этих изображений на стороне сервера). В браузере Amazon Silk эта функциональность реализована также путем «облачной» компрессии изображений (т.е. через их собственные прокси сервера), которые впоследствии посылаются на пользовательское устройство. Google Chrome тоже предоставляет пользователям возможность отмены загрузки всех изображений с помощью опции "site preferences" («предпочтения для сайта»).

4. Требования.

Перечисленные выше прецеденты стали причиной появления следующих требований:

  1. Принимая во внимание возможность художественного редактирования, решение ДОЛЖНО обеспечивать разработчиков возможностью привязки источников изображения к конкретным медиа характеристикам и/или медиа типам. Пользовательскому агенту в свою очередь СЛЕДУЕТ обновлять источник изображения в соответствии с медиа характеристиками и медиа типами динамически изменяющегося окружения браузера.
  2. Решением ДОЛЖЕН быть реализован выбор на основе размера вьюпорта, размера экрана и пиксельного коэффициента устройства (DPR). Выбор корректного изображения для отправки на целевое устройство исходя из полученных данных о размерах и DPR, позволяет избежать таких негативных последствий как задержка загрузки страницы, нецелевое расходование сетевых ресурсов и заряда батареи (антенна мобильного устройства потребляет значительно больше энергии при загрузке контента; на обработку и отображение менее объемных изображений тратится меньше ресурсов, а соответственно и заряда батареи). В некоторых случаях предотвращение загрузки избыточной графической информации может потенциально сэкономить деньги пользователя.
  3. Решение ДОЛЖНО плавно деградировать до функционала поддерживаемого устаревшими пользовательскими агентами, полагаясь, к примеру, на встроенные HTML механизмы обратной совместимости и устаревшие элементы.
  4. Решение ДОЛЖНО предоставлять разработчикам возможность включения контента, совместимого с технологиями обеспечения доступности.
  5. Решение НЕ ДОЛЖНО требовать задействования функционала серверной стороны. Однако, если в этом есть необходимость, серверные адаптации могут иметь место в рамках согласования контента или подобных ей технологий (т.е. они не должны быть взаимоисключающими).
  6. Решением ДОЛЖНА обеспечиваться возможность определения контрольных точек изображений посредством либо минимальных значений (сначала мобильные устройства), либо максимальных значений (сначала настольные ПК) для установления соответствия с используемыми в дизайне медиа запросами.
  7. Решению СЛЕДУЕТ предоставить разработчикам возможность определения изображений в различных форматах (либо ассоциировать набор источников изображений с определенным форматом).
  8. С целью обеспечения совместимости со старыми версиями пользовательских агентов, РЕКОМЕНДУЕТСЯ, чтобы разработчики имели возможность использовать полифилы для адаптации решения. Детально об этом в Рекомендациях рабочей группы TAG W3C для RICG.
  9. Решению СЛЕДУЕТ обеспечить пользовательские агенты возможностью предоставления их пользователям конфигурации, позволяющей контролировать выбор источника изображений. В качестве примеров настроек предпочтений пользователя можно назвать следующие варианты: «всегда минимальное разрешение», «всегда высокое разрешение», «загружать изображения высокого разрешения, если позволяет скорость сетевого соединения» и т.д. Здесь следует уточнить, что реализация подобных настроек пользовательских предпочтений не должна обеспечиваться пользовательскими агентами, а осуществляться за счет конструктивных особенностей самого решения.
  10. Для того, чтобы избежать внесения задержек в процесс загрузки страницы, решение ДОЛЖНО быть надлежащим образом интегрировано с существующими средствами оптимизации, предоставляемыми браузерами (решение, к примеру, должно прекрасно взаимодействовать со сканером предварительной загрузки браузера). В частности, необходимо чтобы время загрузки страницы в результате применения данного решения было значительно меньше, чем это обеспечивается уже существующими технологиями.

A. Открытые вопросы.

Мы внимательно следим за состоянием открытых вопросов на Github и будем вам признательны, если вы поможете нам закрыть их.

История изменений.

Полная история изменений доступна на Github.

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

B. Благодарности.

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

Редакторы выражают благодарность следующим людям за рецензирование документа: Mike Taylor, Doug Shults, Barbara Barbosa Neves, Eileen Webb и Anselm Hannemann.

Этот документ является репродукцией текста Предложения RespImg синтаксиса Таба Аткинса, приведенной здесь согласно C0 лицензии.

Используемое в параграфе «Выбор на основе вьюпорта» изображение представляет собой результат производных работ публикации Пола Роберта Ллойда «Отзывчивые изображения: Что мы думали нам нужно».

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

Полный список участников Общественной группы по отзывчивым изображениям доступен на сайте Общественной W3C группы.