В идеале все эти изображения могли иметь в значительной степени уменьшенные копии, чтобы нормально вписываться в дизайн при отображении на маленьких экранах или при низкой скорости интернета. Даже несмотря на то, что сегодня все новые устройства оснащены превосходными браузерами, пока что не существует быстрого и качественного способа реализовать эту технику. Так что пришло время поговорить о том, как нам хотелось бы видеть эту технологию. Возможно, мы, веб-разработчики, сможем как-то повлиять на развитие спецификации.
Давайте в данном разговоре ограничимся строчными растровыми изображениями. Учитывая сегодняшнее положение в области веб-разработки, нам бы хотелось подразделить наши возможности на три части:
1. Создание нового элемента из существующего только ради того, чтобы решить проблему.
2. Создать новый формат изображения, который бы решил проблему.
3. Ничего не делать, пусть другие решат наши проблемы с помощью технологий.
У каждого из этих пунктов есть свои плюсы и минусы. Давайте рассмотрим.
Создание нового элемента
Делая вывод из обсуждений в сообществе W3C, самым вероятным кандидатом является элемент «picture». Скотт Джелл предложил polyfill на javascript, который отображает нам необходимый функционал. Синтаксис должен быть следующим:
<picture alt="description of image"> <!-- low-res, default --> <source src="small.jpg"> <!-- med-res --> <source src="medium.jpg" media="(min-width: 400px)"> <!-- high-res --> <source src="large.jpg" media="(min-width: 800px)"> <!-- Fallback content --> <img src="small.jpg" alt="description of image"> </picture>Преимущества
* Также работает с другим медиа-синтаксисом типа «video» и «audio», а это имеет значение.
* Возможность отката позволяет нам использовать этот элемент в браузерах, в которых отсутствует его поддержка, а это очень важно. Мы ведь не можем оформлять наш сайт картинками, которые не будут отображаться в старых версиях браузеров.
* Дает нам, разработчикам, возможность отображать именно то, что нужно в определенных ситуациях.
Недостатки
* Элемент в значительной степени более сложный, нежели «img». Сложно учить, сложно выучить, необходимо писать больше кода.
* Немного портит «опрятную репутацию» CSS и HTML за счет внедрения синтаксиса media query в HTML.
* Те же проблемы, по которым строчные стили считаются не очень применимыми. В значительной степени осложняет дальнейшую модернизацию и обновления. К тому же, не дает возможность использовать его повторно.
Новый формат изображения
Стимулом к написанию данной статьи были беседы с Кристофером Шмиттом и его запись в блоге. Кристофер придерживается мнения, что новый формат изображения – это идеальное решение.
Новый формат сможет содержать в себе несколько версий одной и той же информации.
Решение относительно того, какую именно версию изображения следует отобразить, будет производиться на уровне взаимодействия пользовательского браузера и веб-сервера.
Таким образом, хотя файл и будет весить, скажем, 800 кб, но при этом он будет содержать в себе 4 версии изображения, вес которых будет составлять 500, 200, 50 и 10 кб соответственно. Посредством определенных стандартизированных набором установок и правил будет вычислено, какое именно из этих изображений нужно отобразить в браузере.
Кажется фантастикой, не правда ли? Уже существует формат изображения под названием FlashPix, он представляет собой даже более сложную версию предложенной выше идеи. Думаете, что новые форматы изображений невозможно куда-то внедрить? WebP уже сейчас интенсивно зарабатывает поддержку.
В целом, синтаксис может остаться таким же, каким мы его видим сейчас:
<img src="unicorn.rpng" alt="fancy unicorn">Мы только что придумали это расширение файлов, но «responsive PNG» вполне подходит.
Кристоферу нравится подобный подход, так как это позволит нам продолжить использовать элемент «img», который же на фундаментальном уровне «въелся» в основу Веб.
Нам тоже нравится эта идея. Не нужно будет отворачиваться от привычного нам элемента, который преданно служил нам все эти годы. Конечно же, не стоит этого делать. Нет никакой необходимости заменять элемент «img», который стремительно развивается и постоянно предлагает нам новые возможности.
Преимущества
* Синтаксис остается на простом уровне. Работает по тому же принципу, по которому мы используем его сегодня.
* Процесс разработки также остается простым. Один файл вместо множества. Адаптация, вероятно, пройдет быстрее любых других методов, и многим людям это сразу же придется по душе (так как вряд ли кому-то понравится идея с созданием 4 версий файла и вызовом нужной версии посредством media queries).
Недостатки
* Возможна потеря контроля. Для того чтобы все оставалось простым, формат изображения должен быть разработан и использоваться, руководствуясь логике. Будет ли все сделан правильный запрос? Что может повлиять на эту «правильность»? Что насчет ширины родительского контейнера? Что насчет скорости подключения к интернету? Пиксельного разрешения?
* Нет возможности произвести откат. Как же быть с браузерами, которые не поддерживают новый формат?
Другие идеи
Конечно же, здесь мы можем положиться и на javascript. Эта технология может помочь нам с новым форматом изображения. Мы можем использовать традиционные старые форматы png или jpg в нашем элементе «img», и иметь возможность изменить значение параметра src, заменить значение на новый формат до тех пор, пока развитие технологий не дойдет до повсеместно принятого единого формата и метода его применения. Немного неуклюже, конечно, но зато работает.
Если js может сделать такое, возможно стоит поручить данной технологии найти полноценное решение проблемы? javascript позволяет нам делать все «тесты», которые нужно (например, разузнать размер окна браузера, узнать скорость соединения посетителя и так далее), так почему бы не задействовать технологию в замене значения параметра src на значение, ведущее к изображению нужных размеров? Библиотека foresight.js от Адама Брэдли практически это и делат. Возможно, именно для этого нам и нужна технология JS, и нам не нужно создавать себе лишних проблем.
Вам кажется, что принцип функционирования javascript на клиентской стороне не идеален? Но ведь есть несколько решений относительно того, как перекинуть обязанности на сторону сервера.
Адаптивные изображения от Мэтта Уилкокса – это очень интеллектуальное решение, в котором задействована лишь малая часть JS, только для определения текущего разрешения экрана и для записи cookies. Впоследствии все изображения проводятся через PHP-код, который определяет, какая версия изображения на сервере соответствует размеру экрана посетителя.
Sencha.io Src – это еще одно решение, в котором нет ни единого символа кода javascript. Здесь используется UA sniffing для определения устройства, с которого производится запрос, и на какое разрешение экрана нужно опираться. Вам остается лишь присоединять URL сервиса Sencha к значению SRC, ведущему к изображению:
<img src='http://src.sencha.io/http://mywebsite.com/images/unicorn-hires.jpg' alt="unicorn" />Это наиболее простой вариант реализации данной технологии. Конечно же, сервис пока что находится в стадии бета, так что не пугайтесь возможных соответствующих недочетов в его работе (например, если сервис перестанет отвечать, то ваши изображения просто перестанут отображаться). Лично нам кажется, что после официального запуска сервис станет платным.
Преимущества
* Нам не придется расшатывать лодку стандартов Веб.
* Нам не придется ждать, пока все браузеры будут оборудованы соответствующей поддержкой.
Недостатки
* Не игнорирование ли это самой проблемы? Не должны ли стандарты способствовать разрешению настоящих проблем?
* Нам придется писать крайне неуклюжий код.
На чем мы остановились
Нам не особо нравится полагаться на устаревшие технологии и прибегать к использованию хаков, но мы пока что не можем решить, что же лучше – новый формат или новый синтаксис? Может быть они оба хороши? Может быть из них можно сделать комбинацию? Нам кажется, что дело идет на сторону синтаксиса, все же, так как его гораздо больше обсуждают в интернете. Формат – это слишком громко, и нам пока что не удалось найти хотя бы намек на старт разработки подобной технологии.
Будет классно, когда у нас появится возможность подкрепить данную статью реальными примерами реализации!
