Адаптивные изображения и веб-стандарты на распутье

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

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

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

Как долго, странно, и т.д.

Давайте еще раз пройдем по пути, который привел нас к этому моменту, и прочувствуем его:

Самые ранние обсуждения адаптивных изображений начались — кто бы мог подумать — в контексте адаптивного дизайна. Для полноценного изображения в резиновом контейнере требуется картинка, достаточно большая, чтобы покрыть самый широкий из возможных дисплеев. Изображение, спроектированное для того, чтобы охватить контейнер в две тысячи пискелей шириной, должно иметь ширину не менее двух тысяч пикселей. Уменьшение размеров такого изображения для того, чтобы оно уместилось на маленьком экране — тривиальная задача для CSS, но вес такого изображения не меняется, а чем меньше размер экрана, тем больше вероятность того, что скорость передачи данных будет невысока.

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

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

Те из нас, кто работал над проблемой сформировали Общественную группу по адаптивным изображениям (Responsive Images Community Group — RICG), чтобы облегчить общение с органами по стандартизации и представителями браузеров.

W3C создало Общественную группу и Бизнес-группу, чтобы у разработчиков, дизайнеров и любого заинтересованного в Веб была площадка для обсуждения и публикации документов.

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

Предложенные паттерны разметки

Паттерн, предложенный WHATWG на данный момент — это новый набор атрибутов для элемента img. Насколько я могу судить из дискуссии, эта разметка призвана решить две очень специфические проблемы: эквивалент медиа-запросу "min-width" записью типа "600w 200h", и указание плотности пикселей записью типа "1x"/"2x".

Предложенный синтаксис таков:

<img src="face-600-200@1.jpg" alt=""
    set="face-600-200@1.jpg 600w 200h 1x,
         face-600-200@2.jpg 600w 200h 2x,
         face-icon.png      200w 200h">

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

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

Наша разметка была такой:

<picture alt="">
   <source src="mobile.jpg" />
   <source src="large.jpg" media="min-width: 600px" />
   <source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" />
   <img src="mobile.jpg" />
</picture>

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

Поддержка в старых браузерах

Пока существуют два решения, обеспечивающие поддержку picture, предложенного RICG, в старых браузерах: Picturefill Скота Джела (Stott Jehl) и jQuery Picture Аббана Данна (Abban Dunne).

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

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

Вопреки предложениям

Участники WHATWG в публичной почтовой рассылке и через IRC-канал #WHATWG заявили, что представители браузеров предпочли паттерн img set, что является важным фактором для всех обсуждений. Большинство членов WHATWG являются представителями основных браузеров, таким образом они понимают браузерную составляющую лучше чем кто-либо.

С другой стороны, сообщество веб-разработчиков решительно выступило в поддержку паттерна разметки picture. Множество разработчиков, знакомых с ситуацией, недвусмысленно заявили, что синтаксис img set, в лучшем случае, непривычный и, в худшем случае, совершенно нечитаем. Я не могу припомнить, чтобы я когда-либо выдел такое единство среди сообщества во время обсуждения веб-стандартов в прошлом, и, мало того, в разговорах о семантике разметки!

Мы в одной команде

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

По этой причине (для тех, кто использует веб) особенно важно не воспринимать эти дискуссии как «мы против них». Представители стандартов, представители браузеров и разработчики являются партнерами в этом стремлении. Мы все служим высшей цели: сделать веб доступным, удобным и замечательным для всех. И независимо от нашей позиции по img src или picture, я уверен, что все, участвующие в этом, работают над единой целью и мы все согласны, что задача надождения «наибольшего общего знаменателя» непоколебима. Мы просто не можем без разбора оперировать огромными изображениями в высоком разрешении. Их потенциальная стоимость для наших пользователей слишком высока — особенно учитывая десятки тысяч пользователей в развивающихся странах, которые платят за каждый дополнительный килобайт который они скачивают, не получая никакой видимой пользы от того, что они загрузили громадный файл.

Тем не менее, у меня есть несколько важных вопросов к синтаксису img set, по крайней мере в его текущей инкарнации:

1. Сценарии использования

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

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

В настоящее время список сценариев для img set не опубликован. Мы работаем отталкиваясь от предположений, основанных на обсуждении в рассылках WHATWG и в IRC-канале, про то, что img set охватывает два конкретных варианта использования: предоставляет изображения высокого разрешения для экранов с высоким разрешением и обеспечмвает функциональность, похожую на функциональность медиа-запросов min-width, путем добавления строки 600w.

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

Мы можем имень не менее прочный функдамент, используя тег img, но в неизбежно фрагментированном виде.

2. Право на ошибку

Я не отрицаю, что разметка у img set очень непонятная. Это паттерн разметки, непохожий ни на что, виденное нами прежде в HTML или CSS. Он выходит далеко за рамки предпочтений автора. Незнакомый синтаксис неизбежно приведет к ошибкам автора контента, в результате которых проиграет конечный пользователь.

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

<img src="face-600-200@1.jpeg" alt=""
       set="face-600-200@1.jpeg 600w 1x,
           face-600-200@2.jpeg  600w 2x,
           face-icon.png        200w">

Который превращается в:

<img src="face-600-200@1.jpeg" alt=""
      set="face-600-200@1.jpeg 600 1x,
           face-600-200@2.jpeg 600 2x,
           face-icon.png       200">

Или в:

<img src="face-600-200@1.jpeg" alt=""
      set="face-600-200@1.jpeg, 600w 1x
           face-600-200@2.jpeg  600w 2x,
           face-icon.png        200w">

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

Я не утверждаю, что я умнее среднего разработчика, но я говорю как основной разработчик jQuery Mobile и формирую свое мнение основываясь на опыте разработки адаптивного сайта BostonGlobe.com: составлять наборы изображений, основываясь на возможностях клиента — моя работа. Если быть абсолютно честным, я все еще не понимаю предложенное поведение полностью.

Мне неприятно думать, что мы будем прокладывать путь через бесчисленные ошибки просто потому, что img set проще реализовать в браузерах. Реализация в браузере делается раз и на всегда; разработка сайтов делается тысячи и тысячи раз. А согласно принципам дизайна HTML5 нужды авторов сайтов должны преобладать над нуждами разработчиков браузеров. Не говоря уже о других принципах HTML5: решать реальные задачи, идти прямым путем, поддерживать существующий контент и избегать ненужной сложности.

Избегаем ненужной сложности

Авторы не должны быть обременены дополнительными сложностями. Если его все-таки внедрят, img set обеспечит бесчисленное множество мест, где может произойти сбой и, что еще хуже, множество из них настолько неочевидны, что авторы просто не смогут их избежать.

Я уверен, что никто не станет утверждать, что элементы audio и video являются образцом эффективной разметки, но они работают. Хорошо это или плохо, но прецеденты, которые они создали есть и будут. Идите прямым путем. HTML5 оперирует богатым набором медиа-контента именно так — при помощи опциональных источников, и авторы уже знакомы с подобными паттернами разметки. Потенциальный вред от различий в синтаксисе намного перевешивает сиюминутную выгоду для разработчиков.

Любые улучшения по доставке клиентских наборов файлов должно применяться универсально. Представляя совершенно иную систему определения какой набор должен быть доставлен клиенту, улучшения должны быть сделаны два раза, чтобы удовлетворять требованиям двух систем: первы раз, чтобы удовлетворять требованиям media-атрибута, используемого в тегах video, и второй раз, чтобы удовлетворять требованиям только тега img. Такой подход заставит разработчиков поддерживать две базы кода, который, по сути, будет служить одной цели, пока авторы будут учить два различных метода для каждого из сделанных улучшений. Это выглядит как мир до появления стандартов, а не как новый, рациональный мир стандартов, которые должны бы поддерживаться.

Разумные обоснования, о которых не осмеливаются говорить вслух

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

img set — это паттерн, предложенный разработчиками со стороны браузеров, что, безусловно, является ключевым фактором, но это не оправдывает ущербность решения. Меня беспокоит, что невысказанный аргумент в почтовой рассылке WHATWG против picture звучал так: «он не был придуман нами». Я опасаюсь того, что последствия подобной укоренившейся философии могут отразиться на наших пользователях. Именно они будут страдать когда наши сайты упадут (или когда разработчики, неспособные понять сложный синтаксис WHATWG, просто заставят своих пользователей грузить огромные файлы изображений).

Именно мы делаем сайты

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

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

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

Перевод статьи «Responsive Images and Web Standards at the Turning Point», автора Mat "Wilto" Marquis, переводчик — GreatRash

P.S. Это тоже может быть интересно:

7 Комментарии

  1. Павел Радьков

    В разделе «2. Право на ошибку» примеры кода 1 и 3 абсолютно одинаковые. Подсветите что ли изменения в коде, а то игра «найди 10 отличий» утомляет :)

    1. Сергей

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

    2. psywalker

      Ничего страшного, это полезно :)

      1. Павел Радьков

        Да уж, ощутил на себе недостатки этого синтаксиса :)

  2. clavin

    А переносы строк разве разрешены внутри атрибутов? Значение атрибута «set» сделано странным и непривычным, содержащим переносы строк.
    Что по мне, так это использование атрибута «set», чем непонятной и запутывающей конструкции, которой предлагает автор. Излишняя сложность какая-то появляется, и множество тегов. Так что разработчики браузеров, на мой взгляд, избрали лучшее решение.

    1. SelenIT

      Переносы разрешены, только в разных атрибутах по-разному интерпретируются. В данном случае, видимо, эквивалентны обычному пробелу, запись в столбик исключительно для читаемости (хотя это «на вкус на цвет»).

  3. danik

    WHATWG какойто велосипед изобрели с синтаксисом. Вариант с <picture /> куда более удачен, и совпадает с <video /> , как было отмеченно, тоесть ничего придумывать не  надо, новый синтаксис осваивать также не нужно. Так и охота по щам надавать им!

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

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