Станет ли адаптивный контейнер шагом вперёд в развитии изображений?

Целью переиздания оригинальной статьи от Yoav является повышение информационной поддержки и оказание помощи при работе с адаптивными изображениями. Мы с нетерпением ждем ваши отзывы и мнения в комментариях! – Ред.

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

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

“У кого-то есть возражения против решений, связанных с разметкой?”

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

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

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

Чрезмерная подробность.

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

Смешивание представления и контента.

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

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

Определение точек прерывания, основанных на окне просмотра.

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

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

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

В некоторых случаях осуществляется ненужная загрузка.

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

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

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

Зачем нам нужен улучшенный формат файла?

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

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

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

Почему не прогрессивный JPEG формат?

Прогрессивный JPEG формат (Joint Photographic Experts Group – Объединённая группа экспертов по машинной обработке фотографических изображений) теоретически мог бы использоваться для переключения между вариантами с различным разрешением, но это было бы довольно трудно. Данный формат используется со строгими ограничениями на низкое качество изображения и из-за этого очень часто слишком увеличивается общий вес данных. Кроме того, ограничена минимальная разница между разрешениями, что не позволяет кодировщику получить достаточный контроль для получения оптимального варианта изображения. Кроме того, прогрессивный JPEG формат не предполагает выполнение художественной обработки.

Как должен выглядеть искомый формат?

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

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

Как всё это работает?

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

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