Главная / HTML5 / Адаптивные изображения в HTML5: конец первого раунда

Адаптивные изображения в HTML5: конец первого раунда5

16 мая 2012 HTML5, Статьи 608

Брюс Лоусон, среда, 16 мая 2012

После Великого Апрельского Браузерно-Префиксного Тарарама пришла Великая Майская Адаптивно-Картиночная Шумиха 2012-го.

Адаптивные изображения — очередная неразгаданная загадка «отзывчивого» веб-дизайна. Вы отдаете большие картинки высокого разрешения, подходящие для экранов типа «ретины», которые устройства с меньшим разрешением показывают уменьшенными, зря расходуя трафик? Или вы отдаете картинки низкого разрешения, которые мерзко выглядят, будучи растянутыми на большом экране? Вебмастерам приходится рассчитывать на искусные хаки, чтобы отдавать различные контентные картинки (т.е. <img> в HTML, а не CSS-фоны) для разных типов устройств.

В ноябре 2011-го я был настолько разочарован тем, что никто из авторов спецификации даже не рассматривает проблему, что я предложил «для затравки» элемент <picture>, использовавший тот же механизм переключения исходных файлов, что <video> в HTML5:

<picture alt="злой пират">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- запасной вариант для неподдерживающих браузеров -->
      <img src=midres.png alt="злой пират">
</picture>

Примерно в то же время другие независимо пришли к той же мысли, и им было предложено создать общественную группу W3C для обсуждения этого, что они и сделали. Однако, в январе редактор HTML5 Айэн Хиксон сказал:

В каких случаях это может быть нужно для картинок в <img>? Как правило, элемент <img> служит для картинок в контенте, где обычно не нужно ничего адаптировать.

Энтузиазм тех веб-разработчиков из Общественной группы адаптивных изображений W3C порядком сник оттого, что их игнорируют, поскольку самой проблемы никто в упор не видит. Но на этой неделе Эдвард О’Коннор из Эпла предложил другой метод, использующий новый атрибут srcset элемента <img>. Это дополнило его же февральское аналогичное предложение по поводу img-set в CSS, которое уже вошло в WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superpuperhires.jpg 6.5x"
     alt="годный Alt-текст для foo.">

Числа «2» и «6.5x» говорят браузеру об относительных разрешениях: у foo-hires.jpg разрешение в 2 раза больше, чем у foo-lores.jpg.

Спустя всего несколько дней вариант эпловского предложения был добавлен в спецификацию.

Между <picture> и srcset — два важных различия. Самое очевидное — то, что srcset использует элемент <img>, что замечательно, поскольку это самое логичное место для картинок, адаптивных и нет (с <img> не пройдет тот же фокус, что с <video> + <source>, потому что это — пустой элемент, у которого не может быть потомков; решение О’Коннора использует атрибуты, что хорошо).

Второе важное отличие в том, что оно не использует медиавыражений. С медиавыражениями вебмастеру приходится думать о любых изменениях размера области просмотра, ориентации, плотности пикселей, глубины цвета, соотношения сторон и т.п., решать, как угодить им (если придется), определять границы перехода и выражать всё это в коде. Это порядком напрягает мозги разработчика и выливается в «много букв» кода: страничка с 20 картинками, каждая с 5 медиавыражениями для 5 элементов <source>, быстро разрастается в объеме кода.

О’Коннор написал:

Почему указывать масштаб, а не медиавыражение? Ну, медиавыражения — это требования к состоянию браузера, тогда как мы утверждаем что-то об отношениях между ресурсами картинок. Кроме того, браузеры должны быть свободны в использовании того ресурса, который, на их взгляд, лучше всего подходит к текущей ситуации, учитывая не только «медиавыражаемые» вещи типа разрешения устройства, но и масштаб, заданный для <img> через CSS, его атрибуты width=”" и height=”", и даже вещи вроде текущего масштаба всей страницы.

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

Таким образом, когда мы все будем жить в космосе и смотреть 3D-голограммы, устройство на iDroid3000 сможет само определить близость черной дыры (черные дыры, как известно каждому школьнику, вызывают «тормоза» голограмм) и выбрать правильную картинку; нам не придется изобретать медиавыражений для близости черных дыр и задним числом дописывать их на сайты.

У решения с srcset есть две проблемы. Первая очень субъективна, но многие чувствуют то же самое: в том виде, как оно есть в текущем, первом черновике спецификации, синтаксис просто отвратителен!

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

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

Вторая проблема в том, что разработчики не хотят лишиться контроля. Есть проблемы, связанные с художественным замыслом (см. раздел под заголовком «Нужна ли возможность манипулирования изображениями?», он же в нашем переводе), и многих не убеждает, что предложение Эпла решает их, хотя сторонники srcset как раз убеждены, что он учитывает все те случаи.

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

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

Так что подключайтесь. Читайте обсуждения и вносите свою лепту. А как только пыль уляжется и спецификация устаканится, мы, доктора, поставим окончательный диагноз.

Оригинал статьи и автор

Подпишитесь на обновление сайта!

Ваш e-mail:

Понравилась статья? Вы не хотите пропускать новые статьи, посвященные качественной верстке? Тогда подпишитесь на RSS или на электронный ящик и получайте новые статьи мгновенно! Также можете следить за нами в Twitter.

5 комментариев

  • ShumNo:

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

    А для сервера не очень вместо хранения 1 картинки нужно будет хранить 2-3 да еще и генерировать их из исходной. да и сайтов где графика по ширине более 1100 пикселей единицы

    • SelenIT:

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

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

  • SelenIT:

    В комментах к оригинальной статье вскрылось много интересного. Оказывается эти жуткие «600w 200h 2x» в нынешнем синтаксисе — всё-таки не характеристики картинки, а именно граничные условия для вьюпорта, минималные ширина, высота и площадь пикселей (т.е. те же медиавыражения, только сбоку… и вверх ногами :)). Плюс там прозвучал ряд дельных альтернативных предложений, например, с использованием элемента <link>. В общем, будущее веба куется прямо у нас на глазах, так что оставайтесь на связи! :)

  • Nick:

    Логично было бы разделить показ картинок в мобильной версии сайта и полной.Для полной версии можно добавить кнопки скачивания всех версий (с конкретными именами файлов и пометками о разрешении).А в мобильной можно использовать некий упрощенный вариант.

    • SelenIT:

      Отдельная мобильная версия — это всё-таки шаг назад. Сейчас, в связи с взрывным и непредсказуемым расширением зоопарка устройств (нетбуки, планшеты, смартфоны с FullHD-экранами c ладонь, телевизоры, очки виртуальной реальности и т.п.) однозначно поделить версии становится всё труднее. Поэтому набирает популярность "адаптивная верстка", где одна версия подстраивается к любой ситуации. И если в CSS для этого есть Media Queries, то в самом HTML до сих пор таких возможностей было очень мало.

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

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

Мы в социальных сетях

Поддержите наш проект

R356817191883

41001285897040

В примечании к платежу укажите: "Помощь проекту".

Подпишись на css-live.ru

и получай обновления по email

Лучшие материалы

Комментарии Просмотры

Мы на Facebook

Мы ВКонтакте