• 8 минут чтения

• Мобильная версия, Колонка мнений, Адаптивный дизайн

• Поделись ТвиттерЛинкедин

WebKit сделал несколько серьезных новостей, наконец[реализовав[implementingthesrcset атрибут. Как председатель группы сообщества адаптивных изображений W3C, я уже некоторое время попеременно надеялся на этот момент и опасался его.

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

Что это делает?

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

<img src="https://www.smashingmagazine.com/2013/08/webkit-implements-srcset-and-why-its-a-good-thing/low-res.jpg" srcset="https://www.smashingmagazine.com/high-res.jpg 2x">

Не так уж и страшна эта разметка. На простом английском:

«Использовать низкое разрешение.jpg в качестве источника для этого img на дисплеях с низким разрешением и для любого браузера, который не понимает srcset атрибут. Использовать высокое разрешение.jpg в качестве источника для этого img на дисплеях с высоким разрешением в браузерах, которые понимают srcset атрибут.»

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

Рекомендуемое чтение: Адаптивные изображения, сделанные правильно: руководство по и

Разве мы не можем сделать это с помощью JavaScript?

На поверхности, srcset ничего особенного не делает — выбирает подходящий источник из атрибута и меняет содержимое img теги src. Замена содержимого атрибута — это то, что мы делали с JavaScript с незапамятных времен. Ну, с 90-х, во всяком случае. Итак, что это дает нам?

На самом деле мы попытались использовать этот подход на BostonGlobe.com, одном из первых сайтов, где использовалось какое-либо решение с «отзывчивыми изображениями». Благодаря все более агрессивной предварительной выборке в некоторых основных браузерах src запрашивается задолго до того, как у нас появится возможность применить какой-либо пользовательский сценарий: в конечном итоге мы будем делать два запроса для каждого отображаемого изображения, нарушая всю цель. Я задокументировал некоторые из этих усилий в другом месте, поэтому я избавлю вас от кровавых подробностей здесь.

Разве мы не можем сделать это с помощью CSS?

«И да и нет.» Мы можем сделать это с фоновыми изображениями достаточно легко, используя комбинацию медиа-запросов, связанных с плотностью пикселей. srcset как реализовано WebKit, очень похоже на недавний image-set функция, которую они представили в CSS. image-set позволяет вам указать список источников и разрешений фонового изображения и позволить браузеру принять решение о том, какой из них наиболее подходит — довольно знакомые вещи. У нас не было ничего подобного для непрезентационных содержание изображения, правда, до сих пор.

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

Рекомендуемое чтение: Адаптивные изображения в WordPress с художественным оформлением

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

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

Что он делает с пропускной способностью?

Независимо от плотности экрана, есть ряд ситуаций, когда источники изображений с более низким разрешением могут быть предпочтительнее: например, Retina MacBook Pro, привязанный к 3G, или нестабильная сеть Wi-Fi конференции — обе ситуации мы все сталкивались много раз. .

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

Это не часть раннего WebKit srcset реализации, но открывает путь для их добавления, не требуя каких-либо изменений в нашей разметке. Мы, разработчики, можем смело использовать srcset сегодня, и эти оптимизации могут быть «бесплатными» в будущем.

Что это значит для picture Элемент?

Здесь все становится интереснее.

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

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

<img src="https://www.smashingmagazine.com/2013/08/webkit-implements-srcset-and-why-its-a-good-thing/fallback.jpg" srcset="https://www.smashingmagazine.com/small.jpg 640w 1x, https://www.smashingmagazine.com/small-hd.jpg 640w 2x, https://www.smashingmagazine.com/large.jpg 1x, https://www.smashingmagazine.com/large-hd.jpg 2x" alt="...">

На наш взгляд не идеален этот шаблон разметки. Мы ограничены эквивалентом max-width медиа-запросы, пиксели и непостижимый микросинтаксис — все ради дублирования функции медиа-запросов. К счастью для нас, ни веб-разработчики, ни представители браузеров не особенно любят этот чрезмерно расширенный синтаксис — будем надеяться, что он никогда не увидит свет.

То picture Элемент существует для решения этих вариантов использования с использованием более гибкого и знакомого синтаксиса. picture использует media атрибуты на source элементы, похожие на video элемент. Это позволяет нам нацеливать источники изображений на комбинацию факторов: высота и/или ширина области просмотра, в пикселях или emс, используя либо min или max значения — так же, как медиа-запросы в нашем CSS.

<picture>
    <source src="https://www.smashingmagazine.com/2013/08/webkit-implements-srcset-and-why-its-a-good-thing/med.jpg" media="(min-width: 40em)" />
    <source src="sm.jpg" />
    <img src="https://www.smashingmagazine.com/2013/08/webkit-implements-srcset-and-why-its-a-good-thing/fallback.jpg" alt="" />
</picture>

То picture спецификация была написана с этим сокращенным srcset синтаксиса, чтобы его можно было использовать на pictureх source элементы, а также img элементы.

<picture>
    <source srcset="https://www.smashingmagazine.com/med.jpg 1x, https://www.smashingmagazine.com/med-hd.jpg 2x" media="(min-width: 40em)" /> 
    <source srcset="https://www.smashingmagazine.com/sm.jpg 1x, https://www.smashingmagazine.com/sm-hd.jpg 2x" /> 
    <img src="https://www.smashingmagazine.com/2013/08/webkit-implements-srcset-and-why-its-a-good-thing/fallback.jpg" alt="" />
</picture>

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

Итак, это Является Хорошие новости

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

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

Я также писал о проблемах с адаптивными изображениями и решениях, которые мы нашли при работе над веб-сайтом BostonGlobe, в главе «Проблемы и решения в адаптивном веб-дизайне» предстоящей книги Smashing Book 4. не разочароваться.

(вф, ил)