Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
Тихий ужас.
Почему?
Да потому что опять перекладывают оформление в модель. css в html.
Это не оформление в чистом виде, это информация об источниках картинки — ничего не поделаешь, только так сейчас можно решить эту проблему.
Ну к оформлению здесь можно отнести максимум sizes, и то ничто не мешает прописать вам стопы размеров для картинок в CSS. Это работает, хоть и с глюками.
Представил как контент-менеджеру работать с этим. Ну и размер html растет, замусоривается.
А это не задача контент-менеджера совсем, а задача CMS. Его задача картинку загрузить, а система сама сгенерит и разные форматы и разные разрешения
Поддерживаю
Почему это лучше чем
Почему это лучше чем
<img src="opera-closeup-400.jpg" class="w0-400" />
<img src="opera-closeup-1000.jpg" class="w400-1000" />
<img src="opera-closeup-1400.jpg" class="w1000-more" />
с соотвествующими правилами в CSS.
Очень удивился, что автор статьи не pepelsbey: Сколько нужно верстальщиков, чтобы вставить <picture>?.
Будет и моя статья :)
Спасибо за доклад, кстати. Если бы не он он, не было бы этой статьи.
Пользуясь случаем, спрошу. Почему браузер так странно себя ведет в этом варианте
Он полностью игнорирует атрибут
<img
src="images/400crop.jpg"
srcset="images/400.jpg 400w, images/800.jpg 800w, images/1200.jpg 1200w"
width="200"
>
Он полностью игнорирует атрибут
width и загружает максимальное изображение на 1200
Раньше верстальщики и дизайнеры мечтали чтоб вымерли старые версии браузеров или даже некоторые браузеры целиком.
Скоро будут мечтать чтоб вымерли старые версии устройств с небольшой плотностью пикселов на экранах.
Скоро будут мечтать чтоб вымерли старые версии устройств с небольшой плотностью пикселов на экранах.
Атрибут «srcset» вполне логичный и нужный, но я совсем не понимаю зачем пихать css в виде «sizes» прям в html код
Сложив первые буквы, получаем мнемонику РАФКЛучше ФРАК.
Было бы неплохо, если бы браузеры умели распознавать зум и подставлять картинку в большем разрешении.
На многих сайтах вставляют превьюшки, по которым надо кликнуть для просмотра в большем разрешении, часто с переходом на другую страницу — на телефонах было бы намного удобней, если бы подгружалась бóльшая картинка по мере зума пальцами.
К сожалению, я так и не понял, как прикладными средствами отлавливать событие zoom.
На многих сайтах вставляют превьюшки, по которым надо кликнуть для просмотра в большем разрешении, часто с переходом на другую страницу — на телефонах было бы намного удобней, если бы подгружалась бóльшая картинка по мере зума пальцами.
К сожалению, я так и не понял, как прикладными средствами отлавливать событие zoom.
То есть одна и та же картинка, на мониторе с низким разрешением нормально выглядят, а на ретине мыло сплошное? Может что-то не так с монитором, а не картинкой?
На мой взгляд, метаинформация о типе, разрешении, плотности точек не должна быть ни в html ни в css. Этой информации самое место в uri, который уже может использоваться как в html, так и в css, да и где угодно, единообразно:
И так далеее.
На мой взгляд, метаинформация о типе, разрешении, плотности точек не должна быть ни в html ни в css. Этой информации самое место в uri, который уже может использоваться как в html, так и в css, да и где угодно, единообразно:
<img src="wallpaper.jpg?meta:width=800&meta:height=600&meta:dpi=72#or#wallpaper-x2.jpg?meta:width=800&meta:height=600&meta:dpi=150#or#wallpaper.svg?meta:mime=text/svg" />
body {
background: url( 'wallpaper.jpg?meta:width=800&meta:height=600&meta:dpi=72#or#wallpaper-x2.jpg?meta:width=800&meta:height=600&meta:dpi=150#or#wallpaper.svg?meta:mime=text/svg' );
}
<script src="index.js?meta:mime=text/javascript#or#index.ts?meta:mime=text/x-typescript"></script>
И так далеее.
Можно и ещё проще — отдавал бы браузер в HTTP-заголовке размер вьюпорта и плотность пикселей. А на сервере уже каким-нибудь несложным плагином это всё разруливать. Понятно, что «чисто статика» так не взлетит (и, наверное, это плохо). Но вот на комментарий ниже RMV1983 написал, почему жесткий хардкод всех вариантов тоже плох.
Кстати, был бы в http-заголовке размер вьюпорта, ещё ряд проблем с адаптивностью можно было бы решить (например, при первой загрузке сразу выдавать нужные размеры html-блоков на сервере, или нужные css-файлы).
Кстати, был бы в http-заголовке размер вьюпорта, ещё ряд проблем с адаптивностью можно было бы решить (например, при первой загрузке сразу выдавать нужные размеры html-блоков на сервере, или нужные css-файлы).
Вы сейчас про HTTP Client Hints говорите.
Недостаток его в том, что надо реализовывать и на сервере, и на клиенте.
Недостаток его в том, что надо реализовывать и на сервере, и на клиенте.
B кто должен формировать этот мета запрос? браузер? и потом сервер его еще понять и отдать нужный контент. Получается что реализацию должна быть двухсторонней в отличие от picture
А если происходит динамическое изменение вьюпорта? Тогда как быть.
А если происходит динамическое изменение вьюпорта? Тогда как быть.
Формирует программист, а понимает браузер, загружая «wallpaper.jpg?meta:width=800&meta:height=600&meta:dpi=72» или «wallpaper-x2.jpg?meta:width=800&meta:height=600&meta:dpi=150» или «wallpaper.svg?meta:mime=text/svg» в зависимости от того, что лучше подходит. Серверу не нужно его понимать — при отдаче статики он просто игнорирует query string. При изменении вьюпорта, если уже есть загруженная картинка в большем разрешении или в векторном формате, то просто ресемплит, иначе показывает что есть, а в фоне подгружает хайрез.
Не, это очень плохая идея. URL указывает на несколько ресурсов вместо одного. Параметры переданные в урл игнорируются и используются почему-то браузером. Человеку такую кашу параметров читать невозможно.
А что плохого в том, что uri указывает на несколько ресурсов? Точнее представляет из себя просто список uri.
Параметры могут игнорироваться, а могут и нет:
В этом случае сервер генерирует картинку с нужной плотностью в зависимости от параметров.
При наличие подсветки синтаксиса читать не сложнее, чем нагромождение picture, img, src, srcset и пр.
Параметры могут игнорироваться, а могут и нет:
<img src="generate?meta:dpi=72#or#generate?meta:dpi=150#or#generate?meta:dpi=300" />
В этом случае сервер генерирует картинку с нужной плотностью в зависимости от параметров.
При наличие подсветки синтаксиса читать не сложнее, чем нагромождение picture, img, src, srcset и пр.
В таком варианте оно выглядит как костыль страшный.
Кроме внесения того, что на конец-то вынесли в css вы предлагаете еще и логику добавить, т.е. «or»
Зачем это все тогда? Проще яваскриптом разруливать, хотя бы все поймут сразу.
Кроме внесения того, что на конец-то вынесли в css вы предлагаете еще и логику добавить, т.е. «or»
Зачем это все тогда? Проще яваскриптом разруливать, хотя бы все поймут сразу.
Я бы не назвал bulk-uri костылём. Соединение через #or# — для обратной совместимости.
Мета информация об изображении ничего не говорит о том, как его следует показывать. meta:width и meta:height — информация о разрешении изображения, необходимая браузеру, чтобы принять решение какой ресурс скачивать и, если в css не сказано иное, сколько места нужно зарезервировать на странице, чтобы не было скачка контента, когда изображение загрузится.
Яваскриптом в css не очень-то удобно рулить.
Мета информация об изображении ничего не говорит о том, как его следует показывать. meta:width и meta:height — информация о разрешении изображения, необходимая браузеру, чтобы принять решение какой ресурс скачивать и, если в css не сказано иное, сколько места нужно зарезервировать на странице, чтобы не было скачка контента, когда изображение загрузится.
Яваскриптом в css не очень-то удобно рулить.
>>Яваскриптом в css не очень-то удобно рулить.
Почему неудобно? Обычная объектная модель, к тому же почти везде jquery.
>>Я бы не назвал bulk-uri костылём. Соединение через #or# — для обратной совместимости.
Дело не только в OR, но само OR там явно не органически выглядит, это все-таки логика, это условие уже, а не просто запятая списка.
Зачем все вообще пихать в один атрибут? запоминать где там двоеточие, где равно, какой-то еще свой синтаксис появляется.
При этом абсолютная мешанина, тут и идентификатор ресурса и его параметры, да это просто читать неприятно,
все-таки мы двигаемся к ускорению разработки, повсеместной подсветки синтаксиса и к автоподстановкам, а тут наоборот.
Еще можно вспомнить про различные парсеры и поисковики
То, что представлено в статье, конечно тоже та еще радость — но там хотя бы сходу понятно о чем речь идет.
Почему неудобно? Обычная объектная модель, к тому же почти везде jquery.
>>Я бы не назвал bulk-uri костылём. Соединение через #or# — для обратной совместимости.
Дело не только в OR, но само OR там явно не органически выглядит, это все-таки логика, это условие уже, а не просто запятая списка.
Зачем все вообще пихать в один атрибут? запоминать где там двоеточие, где равно, какой-то еще свой синтаксис появляется.
При этом абсолютная мешанина, тут и идентификатор ресурса и его параметры, да это просто читать неприятно,
все-таки мы двигаемся к ускорению разработки, повсеместной подсветки синтаксиса и к автоподстановкам, а тут наоборот.
Еще можно вспомнить про различные парсеры и поисковики
То, что представлено в статье, конечно тоже та еще радость — но там хотя бы сходу понятно о чем речь идет.
Потому что у каждого браузера свои особенности. Потому что js — имеративный язык, а css — декларативный. Потому, что модифицируемые налету css сложнее отлаживать. И jquery тут никаким боком.
#or# — вполне себе запятая списка. Никакой особой логики тут нет.
Затем, чтобы иметь возможность использовать один и тот же механизм везде, где надо указывать ссылку. Не только в html, но и в css и прочих местах. Двоеточие отделяет пространство имён от собственно имён. meta — зарезервированное пространство имён.
Идентификатор ресурса почти всегда содержит параметры. Тут они более стандартизированы.
Тут ничего не мешает быстро разрабатывать, подсвечивать синтаксис, автоподставлять и анализировать поисковиками.
Нет, эта запись сходу, без разъяснений не понятна
#or# — вполне себе запятая списка. Никакой особой логики тут нет.
Затем, чтобы иметь возможность использовать один и тот же механизм везде, где надо указывать ссылку. Не только в html, но и в css и прочих местах. Двоеточие отделяет пространство имён от собственно имён. meta — зарезервированное пространство имён.
Идентификатор ресурса почти всегда содержит параметры. Тут они более стандартизированы.
Тут ничего не мешает быстро разрабатывать, подсвечивать синтаксис, автоподставлять и анализировать поисковиками.
Нет, эта запись сходу, без разъяснений не понятна
<source
sizes="(min-width: 640px) 60vw, 100vw"
srcset="opera-closeup-200.webp 200w,
opera-closeup-400.webp 400w,
opera-closeup-800.webp 800w,
opera-closeup-1200.webp 1200w,
opera-closeup-1600.webp 1600w,
opera-closeup-2000.webp 2000w"
type="image/webp">
>>Потому что у каждого браузера свои особенности. Потому что js — имеративный язык, а css — декларативный.
>>Потому, что модифицируемые налету css сложнее отлаживать. И jquery тут никаким боком.
Похоже в данном контексте мы разговариваем немного о разных вещах, в прочем теперь я понял что вы имели ввиду под «Яваскриптом в css не очень-то удобно рулить.»
Я не говорю что понятно, я говорю о том, что понятно о чем идет речь. Это несколько разные вещи.
В этом случае, например, по факту используется привычный синтаксис html, в вашем же нет, вы там свой придумали.
Т.е. вот по-моему: Этот вариант как бы не очень, но ваш точно также не очень, не решает он проблем, а только добавляет.
>>Потому, что модифицируемые налету css сложнее отлаживать. И jquery тут никаким боком.
Похоже в данном контексте мы разговариваем немного о разных вещах, в прочем теперь я понял что вы имели ввиду под «Яваскриптом в css не очень-то удобно рулить.»
Я не говорю что понятно, я говорю о том, что понятно о чем идет речь. Это несколько разные вещи.
В этом случае, например, по факту используется привычный синтаксис html, в вашем же нет, вы там свой придумали.
Т.е. вот по-моему: Этот вариант как бы не очень, но ваш точно также не очень, не решает он проблем, а только добавляет.
Содержимое sizes и srcset — ниразу не «привычный html»
Какие проблемы не решает? «Разрешение» и «Формат» — вполне решает. «Адаптивность» и «Кадрирование» — не место им в html.
Какие проблемы не решает? «Разрешение» и «Формат» — вполне решает. «Адаптивность» и «Кадрирование» — не место им в html.
Я напишу один css для любых фоток. И уж точно я не буду руками делать для каждой картинки несколько дубликатов в разном разрешении с разным кадрированием. Максимум — каждой фотке присвою пару классов, указывающих, какая её часть является наиболее значимой.
>> sizes и srcset — ниразу не «привычный html»
Это атрибуты html тега, это привычно парсерам и людям.
>>«Разрешение» и «Формат» — вполне решает
Вы внутри формата html придумали свой формат, еще одну сущность. Принцип Оккама опять же. Необходимости нет, раз есть возможность сделать как в варианте, описанном в статье.
>> «Адаптивность» и «Кадрирование» — не место им в html.
Что вы имеете ввиду? Во первых, нужно понимать принципы разделения контента и стилей его отображения.
тег img это контент, бекграунд это стиль отображения, хоть там тоже речь об изображении, между ними громадная разница.
Вас же не удивляет, надеюсь, что в теге img есть атрибут src?
Это атрибуты html тега, это привычно парсерам и людям.
>>«Разрешение» и «Формат» — вполне решает
Вы внутри формата html придумали свой формат, еще одну сущность. Принцип Оккама опять же. Необходимости нет, раз есть возможность сделать как в варианте, описанном в статье.
>> «Адаптивность» и «Кадрирование» — не место им в html.
Что вы имеете ввиду? Во первых, нужно понимать принципы разделения контента и стилей его отображения.
тег img это контент, бекграунд это стиль отображения, хоть там тоже речь об изображении, между ними громадная разница.
Вас же не удивляет, надеюсь, что в теге img есть атрибут src?
А атрибуты src и href — не привычны?
Ещё раз подчеркну, предложенный мной вариант не имеет никакого отношения ни к HTML ни к CSS, а является расширением стандарта URI, который перпендикулярен как HTML так и CSS, хотя они и ссылаются на него при определении некоторых свойств. И именно поэтому расширение URI даёт системный эффект, а добавление костылей в html:img, html:picture, html:video, html:audio, html:link, html:script, html:iframe, html:object, css:background-image, css:font-family, css:cursor и прочие места, где бывает необходимо грузить разные ресурсы в зависимости от браузера/вьюпорта/доступной памяти/скорости процессора — нет.
Обрезание и ресайз замечательно реализуются специально предназначенным для этого инструментом — css.
Ещё раз подчеркну, предложенный мной вариант не имеет никакого отношения ни к HTML ни к CSS, а является расширением стандарта URI, который перпендикулярен как HTML так и CSS, хотя они и ссылаются на него при определении некоторых свойств. И именно поэтому расширение URI даёт системный эффект, а добавление костылей в html:img, html:picture, html:video, html:audio, html:link, html:script, html:iframe, html:object, css:background-image, css:font-family, css:cursor и прочие места, где бывает необходимо грузить разные ресурсы в зависимости от браузера/вьюпорта/доступной памяти/скорости процессора — нет.
Обрезание и ресайз замечательно реализуются специально предназначенным для этого инструментом — css.
>>Ещё раз подчеркну, предложенный мной вариант не имеет никакого отношения ни к HTML ни к CSS,
>>а является расширением стандарта URI
Ок, хорошо, можно посмотреть с этой стороны. Стандарт URI четко описан в RFC, если уж предлагаете именно его расширять, делайте не частное прикладное решение, которое вызывает больше проблем, чем их решений, а конкретное и четкое предложение в формате RFC.
Сразу увидите, почему всякие #OR# там будут очень странно смотреться.
>>а является расширением стандарта URI
Ок, хорошо, можно посмотреть с этой стороны. Стандарт URI четко описан в RFC, если уж предлагаете именно его расширять, делайте не частное прикладное решение, которое вызывает больше проблем, чем их решений, а конкретное и четкое предложение в формате RFC.
Сразу увидите, почему всякие #OR# там будут очень странно смотреться.
Я знаком с этим стандартом и, что важнее, с практикой его применения. Всякие "#or#" смотрятся необычно, но всяко не хуже всяких "#!"
Какие именно проблемы вы видите в этом решении? Оно полностью обратно совместимо и довольно расширяемо.
Какие именно проблемы вы видите в этом решении? Оно полностью обратно совместимо и довольно расширяемо.
Тут важна не узкая практика применения стандарта, а практика создания стандартов.
Стандарт URI вещь очень широкого применения, намного более широкого чем проблема различных dpi.
Поэтому я и говорю, что для дальнейшего обсуждения, раз вы предлагаете расширить URI RFC, необходимо увидеть как вы его хотите расширить. Не просто некоторый комментарий описывающий некий частный случай, а предложение в формате RFC.
Стандарт URI вещь очень широкого применения, намного более широкого чем проблема различных dpi.
Поэтому я и говорю, что для дальнейшего обсуждения, раз вы предлагаете расширить URI RFC, необходимо увидеть как вы его хотите расширить. Не просто некоторый комментарий описывающий некий частный случай, а предложение в формате RFC.
Вы прекрасно понимаете, что я не буду тратить кучу времени на написание стандарта, которому никто не будет следовать. Это не важно как именно расширять URI. Приведённый мной пример лишь иллюстрирует как простое и обратно совместимое расширение URI заменяет десяток расширений HTML, XML, CSS, SVG и других языков.
Выглядит как костыль.
Как такие URI кешировать? Ведь кроме браузеров, есть еще куча уровней кеша.
Сколько граблей будет с динамическим изменением всего этого на клиенте?
Почему разделитель hash-части вдруг становится разделителем какой-либо мета-инфромации?
Почему вообще уникальный идентификатор ресурса должен включать в себя какую-то метаинформацию, фактически указывая на несколько различных ресурсов?
Как такие URI кешировать? Ведь кроме браузеров, есть еще куча уровней кеша.
Сколько граблей будет с динамическим изменением всего этого на клиенте?
Почему разделитель hash-части вдруг становится разделителем какой-либо мета-инфромации?
Почему вообще уникальный идентификатор ресурса должен включать в себя какую-то метаинформацию, фактически указывая на несколько различных ресурсов?
А что в html не выглядит как костыль? :-)
А где вы тут видите проблемы с кэшированием?
Никаких граблей не будет.
Для обеспечения обратной совместимости.
А почему не должен? Все уже давно используют указание мета-информации через параметры:
Я лишь предлагаю стандартизировать основные параметры, чтобы ими мог пользоваться браузер.
А где вы тут видите проблемы с кэшированием?
Никаких граблей не будет.
Для обеспечения обратной совместимости.
А почему не должен? Все уже давно используют указание мета-информации через параметры:
<im src="background.jpg?v=2" />
Я лишь предлагаю стандартизировать основные параметры, чтобы ими мог пользоваться браузер.
Как и что будут кешировать кеширующие прокси? Это надо их массово научить парсить хитроумный URI?
Не чувствуете разницу: у двух разных ресурсов два разных URL, а не один URL на несколько разных ресурсов, как предлагаете вы.
<im src="background.jpg?v=1" />
<im src="background.jpg?v=2" />
Не чувствуете разницу: у двух разных ресурсов два разных URL, а не один URL на несколько разных ресурсов, как предлагаете вы.
Кэширующие прокси не надо ничему учить. Это чисто клиентская «фича».
habrahabr.ru/post/237991/#comment_8017927
habrahabr.ru/post/237991/#comment_8017927
Похоже, что этот код picture (тот что в конце статьи) подразумевает, что окончательный синтаксис будет писать не человек. node.js перед загрузкой сайта или class picture на сервере. Поскольку слишком много текста получается и никакой автоматизации,. типа «если не указано обратное, для всех картинок на странице есть три версии плотности, отличия в scr — такие то».
И да, я тоже не понимаю — почему нельзя сразу предусмотреть альтернативный синтаксис на css. Да и зачем picture вообще, если, как мне кажется, можно ограничиться расширением параметров img? С первыми пунктами, на мой взгляд, получилось намного удобнее, чем с последними. Или хотят сделать именно по аналогии с video?
Вопрос по существу — насколько удобно будет решение в следующей гипотетической ситуации: сайт, адаптированный под плотность 1, 2 и 3. Т.е. для всех изображений — есть 3 картинки. Картинок больше 1000, готовил картинки какой-нибудь скрипт. Но вставляли их вручную (или исходник скрипта был утерян, или другой подрядчик и исходники ему не дали — сайт же есть и не зашифрован). Появились новые устройства и требуется поддержка скажем 4 и 5. Теперь собственно вопрос: а чем поможет этот занимательный picture?
В его случае потребуется полностью перелопачивать весь код или на уровне проекта — предусматривать возможность его автоматического изменения! Но в последнем случае — гораздо проще всё сделать на сервере, до отдачи клиенту (предварительно узнав по ajax+js — плотность) или наоборот — отказаться от расширенного image, скриптом подставляя нужное изображение. И кто тогда будет пользоваться picture? Кроме как для одиночной основной картинки?
Если в моих рассуждениях есть ошибка, прошу прояснить. Возможно, что я упустил какой то важный логический шаг. Поскольку кроме как для одиночного использования, применения picture пока что не вижу.
И да, я тоже не понимаю — почему нельзя сразу предусмотреть альтернативный синтаксис на css. Да и зачем picture вообще, если, как мне кажется, можно ограничиться расширением параметров img? С первыми пунктами, на мой взгляд, получилось намного удобнее, чем с последними. Или хотят сделать именно по аналогии с video?
Вопрос по существу — насколько удобно будет решение в следующей гипотетической ситуации: сайт, адаптированный под плотность 1, 2 и 3. Т.е. для всех изображений — есть 3 картинки. Картинок больше 1000, готовил картинки какой-нибудь скрипт. Но вставляли их вручную (или исходник скрипта был утерян, или другой подрядчик и исходники ему не дали — сайт же есть и не зашифрован). Появились новые устройства и требуется поддержка скажем 4 и 5. Теперь собственно вопрос: а чем поможет этот занимательный picture?
В его случае потребуется полностью перелопачивать весь код или на уровне проекта — предусматривать возможность его автоматического изменения! Но в последнем случае — гораздо проще всё сделать на сервере, до отдачи клиенту (предварительно узнав по ajax+js — плотность) или наоборот — отказаться от расширенного image, скриптом подставляя нужное изображение. И кто тогда будет пользоваться picture? Кроме как для одиночной основной картинки?
Если в моих рассуждениях есть ошибка, прошу прояснить. Возможно, что я упустил какой то важный логический шаг. Поскольку кроме как для одиночного использования, применения picture пока что не вижу.
Мне кажется, что проблема выходит за рамки picture и касается внедрения любого нового функционала в существующий контент.
Вы можете по-быстрому использовать текущий метод загрузки через JS, но даже в этом случае вам придется каким-то образом дать ему знать о новой плотности. Если она прописывалась в виде data-x2, data-x3 (так делает HiSRC), то код вам лопатить в любом случае.
Или же можете потратить чуть больше времени и сделать правильно. Получите сразу еще и расширяемую поддержку в будущем (допустим кадрирования когда захотите), поддержку форматов, экономию трафика.
Собственно задача распарсить текущие статьи на предмет тега
Вы можете по-быстрому использовать текущий метод загрузки через JS, но даже в этом случае вам придется каким-то образом дать ему знать о новой плотности. Если она прописывалась в виде data-x2, data-x3 (так делает HiSRC), то код вам лопатить в любом случае.
Или же можете потратить чуть больше времени и сделать правильно. Получите сразу еще и расширяемую поддержку в будущем (допустим кадрирования когда захотите), поддержку форматов, экономию трафика.
Собственно задача распарсить текущие статьи на предмет тега
img и обновить на новый совсем не сложна для бекенда. Выбор за вами.>…касается внедрения любого нового функционала в существующий контент.
Скорее «может касаться», поскольку в некоторых случаях, люди исправляют свои ошибки. И получается то, что не стыдно назвать «продуманным». Про picture лично я пока такого сказать не могу. Но насколько я понимаю, это ещё только развивается, да же в ночные сборки ещё не полностью вошло — может и успеют исправить.
Понятно что выбор есть всегда. Как понятно и то, что если будет функционал, то потом найдут как его использовать. Но пока он ещё только разрабатывается, желательно что бы результат был бы более полезен.
>…но даже в этом случае вам придется каким-то образом дать ему знать о новой плотности.
Как насчёт отдельной функции (или свойства класса) за это отвечающей? Или просто массива доступных элементов по умолчанию?
Скажем, если нет ни одного атрибута data-x?, а класс — fleximg то всем им добавить ещё одну плотность. И все изменения сведутся к новым изображениям и правке кода в одном месте, причём скорее всего — одной строчке! (И не важно: фронтенд это делает или бэкенд)
К picture претензия с моей стороны в том, что вместо того, что бы решать проблему (причём на уровне css), она добавляет новые. Зачем? Существуют решения со схожей эффективностью. Если уж что-то делать, то нужно делать так, что бы стало лучше. И да, в рамках picture можно много чего исправить, да и использовать ограниченно можно (скажем при разметке в WYSIWYG-редактор — для добавления одной картинки), но на данный момент (исходя из статьи) — это создаст больше неудобств, чем даст преимуществ. Может быть я неправ, время — покажет.
>Если она прописывалась в виде data-x2, data-x3 …
Вот в этом случае, я с вами согласен — ничем не лучше. Проблема в том, что picture «рекомендует», «пополяризирует» именно такой и только такой подход.
>Собственно задача распарсить текущие статьи на предмет тега img и обновить на новый совсем не сложна для бекенда. Выбор за вами.
И зачем тут picture? Сейчас это и для фронтенда не особая проблема (если не ставить целью экономию трафика при максимизации качества и скорости отклика одновременно).
Речь идёт о том, что нет (в статье или в принципе?) чётко сформулированной проблемы, которую бы решала picture. Нет сравнения с эффективностью существующих решений. И в то же время её синтаксис кажется черезчур усложнённым, не продуманным до конца.
Скорее «может касаться», поскольку в некоторых случаях, люди исправляют свои ошибки. И получается то, что не стыдно назвать «продуманным». Про picture лично я пока такого сказать не могу. Но насколько я понимаю, это ещё только развивается, да же в ночные сборки ещё не полностью вошло — может и успеют исправить.
Понятно что выбор есть всегда. Как понятно и то, что если будет функционал, то потом найдут как его использовать. Но пока он ещё только разрабатывается, желательно что бы результат был бы более полезен.
>…но даже в этом случае вам придется каким-то образом дать ему знать о новой плотности.
Как насчёт отдельной функции (или свойства класса) за это отвечающей? Или просто массива доступных элементов по умолчанию?
Скажем, если нет ни одного атрибута data-x?, а класс — fleximg то всем им добавить ещё одну плотность. И все изменения сведутся к новым изображениям и правке кода в одном месте, причём скорее всего — одной строчке! (И не важно: фронтенд это делает или бэкенд)
К picture претензия с моей стороны в том, что вместо того, что бы решать проблему (причём на уровне css), она добавляет новые. Зачем? Существуют решения со схожей эффективностью. Если уж что-то делать, то нужно делать так, что бы стало лучше. И да, в рамках picture можно много чего исправить, да и использовать ограниченно можно (скажем при разметке в WYSIWYG-редактор — для добавления одной картинки), но на данный момент (исходя из статьи) — это создаст больше неудобств, чем даст преимуществ. Может быть я неправ, время — покажет.
>Если она прописывалась в виде data-x2, data-x3 …
Вот в этом случае, я с вами согласен — ничем не лучше. Проблема в том, что picture «рекомендует», «пополяризирует» именно такой и только такой подход.
>Собственно задача распарсить текущие статьи на предмет тега img и обновить на новый совсем не сложна для бекенда. Выбор за вами.
И зачем тут picture? Сейчас это и для фронтенда не особая проблема (если не ставить целью экономию трафика при максимизации качества и скорости отклика одновременно).
Речь идёт о том, что нет (в статье или в принципе?) чётко сформулированной проблемы, которую бы решала picture. Нет сравнения с эффективностью существующих решений. И в то же время её синтаксис кажется черезчур усложнённым, не продуманным до конца.
Давайте оставим тему замены существующих тегов на picture в стороне. Это задача без деталей текущей реализации не имеет смысла.
>К picture претензия с моей стороны в том, что вместо того, что бы решать проблему (причём на уровне css)
Я не очень понимаю как вы решите проблему DPI или формата на уровне CSS.
>Проблема в том, что picture «рекомендует», «пополяризирует» именно такой и только такой подход.
Спецификация picture это часть будущего HTML5.1. Это не то, что какие-то дядьки из Оперы запилили и всем навязывают теперь. Изначально она была отдельным документом, но когда все стороны пришли к соглашениям как это должно выглядеть и работать ее включили в HTML и теперь браузеры начали потихоньку это реализовывать.
> Речь идёт о том, что нет (в статье или в принципе?) чётко сформулированной проблемы, которую бы решала picture
Ну здрасьте. РАФК это и есть 4 четко сформулированные проблемы, которые решает picture. Если вам мало, можете почитать расширенное описание на usecases.responsiveimages.org/, там и текущие техники рассмотрены.
>К picture претензия с моей стороны в том, что вместо того, что бы решать проблему (причём на уровне css)
Я не очень понимаю как вы решите проблему DPI или формата на уровне CSS.
>Проблема в том, что picture «рекомендует», «пополяризирует» именно такой и только такой подход.
Спецификация picture это часть будущего HTML5.1. Это не то, что какие-то дядьки из Оперы запилили и всем навязывают теперь. Изначально она была отдельным документом, но когда все стороны пришли к соглашениям как это должно выглядеть и работать ее включили в HTML и теперь браузеры начали потихоньку это реализовывать.
> Речь идёт о том, что нет (в статье или в принципе?) чётко сформулированной проблемы, которую бы решала picture
Ну здрасьте. РАФК это и есть 4 четко сформулированные проблемы, которые решает picture. Если вам мало, можете почитать расширенное описание на usecases.responsiveimages.org/, там и текущие техники рассмотрены.
>Давайте оставим тему замены существующих тегов на picture в стороне.
Давайте. Но делать это похоже всё-равно придётся, для совместимости со старыми браузерами.
>Я не очень понимаю как вы решите проблему DPI или формата на уровне CSS.
Чуть ниже постарался, как смог, проиллюстрировать свою идею. (см. комментарий )
>Спецификация picture это часть будущего HTML5.1.
Именно это и печалит.
>…когда все стороны пришли к соглашениям как это должно выглядеть и работать…
Вероятно что-то недоглядели. Такая реакция, судя по комментариям, не у меня одного. Может, одумаются пока не поздно, да и поменяют спецификацию, пока ещё не внедрили?
>Ну здрасьте. РАФК это и есть 4 четко сформулированные проблемы…
Ну, в вашей статье кейс описан нечётко. Не учтена, к примеру, масштабируемость решения. При том, что для одиночной картинки picture подходит, она явно нуждается в доработке для сотни картинок.
За ссылку спасибо — почитаю.
Самая же главная претензия, что нет сравнения: почему это лучше тех решений, что используются для этих целей сейчас? (по ссылке, при беглом взгляде, этого тоже не увидел)
Давайте. Но делать это похоже всё-равно придётся, для совместимости со старыми браузерами.
>Я не очень понимаю как вы решите проблему DPI или формата на уровне CSS.
Чуть ниже постарался, как смог, проиллюстрировать свою идею. (см. комментарий )
>Спецификация picture это часть будущего HTML5.1.
Именно это и печалит.
>…когда все стороны пришли к соглашениям как это должно выглядеть и работать…
Вероятно что-то недоглядели. Такая реакция, судя по комментариям, не у меня одного. Может, одумаются пока не поздно, да и поменяют спецификацию, пока ещё не внедрили?
>Ну здрасьте. РАФК это и есть 4 четко сформулированные проблемы…
Ну, в вашей статье кейс описан нечётко. Не учтена, к примеру, масштабируемость решения. При том, что для одиночной картинки picture подходит, она явно нуждается в доработке для сотни картинок.
За ссылку спасибо — почитаю.
Самая же главная претензия, что нет сравнения: почему это лучше тех решений, что используются для этих целей сейчас? (по ссылке, при беглом взгляде, этого тоже не увидел)
Совместимость прекрасно обеспечивается через атрибут src.
Сравнивать с текущими методами не входило в мою задумку. На вскидку могу сравнить с методом загрузки через JS в случае высоких DPI
Picture:
1) Не использует JS
2) Сразу грузит нужную картинку
Сравнивать с текущими методами не входило в мою задумку. На вскидку могу сравнить с методом загрузки через JS в случае высоких DPI
Picture:
1) Не использует JS
2) Сразу грузит нужную картинку
Дополню про picture
3) вызывает проблемы совместимости
4) -//- головную боль при изменении более 10 картинок
5) не семантичен
Вы пишите только плюсы, забывая про недостатки.
Я НЕ утверждаю, что правильный вариант только тот что я предложил. Нет. Проблему можно решить разными способами. Лично мне вариант с picture нравится меньше всего.
>Совместимость прекрасно обеспечивается через атрибут src.
Вы проверяли? Точно на всех браузерах? И на links2 (с поддержкой картинок)?
Я понимаю, что хочется, что бы video, audio, picture были семантически похожи, но беда в частоте их использования. Картинок на любом сайте на порядок больше. И если заняться целью их ВСЕ адаптировать… picture будет только мешать. ИМХО
И напишите пожалуйста: почему, скажем, обрезку изображений вы относите к семантике, когда это именно изменение внешнего вида, содержимое то (в идеале) меняться не должно…
3) вызывает проблемы совместимости
4) -//- головную боль при изменении более 10 картинок
5) не семантичен
Вы пишите только плюсы, забывая про недостатки.
Я НЕ утверждаю, что правильный вариант только тот что я предложил. Нет. Проблему можно решить разными способами. Лично мне вариант с picture нравится меньше всего.
>Совместимость прекрасно обеспечивается через атрибут src.
Вы проверяли? Точно на всех браузерах? И на links2 (с поддержкой картинок)?
Я понимаю, что хочется, что бы video, audio, picture были семантически похожи, но беда в частоте их использования. Картинок на любом сайте на порядок больше. И если заняться целью их ВСЕ адаптировать… picture будет только мешать. ИМХО
И напишите пожалуйста: почему, скажем, обрезку изображений вы относите к семантике, когда это именно изменение внешнего вида, содержимое то (в идеале) меняться не должно…
3) Какие?
4) Какую?
5) ЛОЛШТО? как картинка, которая показывает картинку может быть не семантична?
> Вы проверяли? Точно на всех браузерах? И на links2 (с поддержкой картинок)?
А что здесь проверять? Любой браузер игнорирует неизвестные теги и атрибуты
> почему, скажем, обрезку изображений вы относите к семантике, когда это именно изменение внешнего вида, содержимое то (в идеале) меняться не должно…
это не изменение оформления и не семантика. это контент. для больших экранов больше контента, для маленьких меньше.
4) Какую?
5) ЛОЛШТО? как картинка, которая показывает картинку может быть не семантична?
> Вы проверяли? Точно на всех браузерах? И на links2 (с поддержкой картинок)?
А что здесь проверять? Любой браузер игнорирует неизвестные теги и атрибуты
> почему, скажем, обрезку изображений вы относите к семантике, когда это именно изменение внешнего вида, содержимое то (в идеале) меняться не должно…
это не изменение оформления и не семантика. это контент. для больших экранов больше контента, для маленьких меньше.
3) Ну например в существующих WYSIWYG-редакторах
4) Хм… вроде бы уже писал. Есть более 10 (или давайте более 100, если мало — более 1000) картинок. Нужно к каждой из них добавить вариант с точностью x6. Вы предлагаете вручную каждой из них дописывать source, причём не давая альтернатив. Если использовать picture.
5) Просто. Картинки бывают разными. Сама картинка (одна) — вполне семантична. Но вот беда, вы же предлагаете. что одна картика — то не одна картинка, это куча картинок, которые притворяются одной. И где тут семантичность?
>Любой браузер игнорирует неизвестные теги и атрибуты…
Кхм. Ну да. Верно. Похоже, что тут проблем с браузерами не будет. Зато с редакторами кода — будут.
>это не изменение оформления и не семантика. это контент. для больших экранов больше контента, для маленьких меньше.
В том то и дело, что это НЕ контент, а оформление. контент — это только первоначальная картинка А её варианты — уже оформление. Вы же не будете утверждать. что картинки по смыслу должны быть абсолютно разными для разных экранов? Они должны быть похожими, но адаптированными. А раз похожими — значит они производные от первоначальной и сиё должно быть автоматизированно. При этом, если человек захочет, то он должен иместь возможность сделать и так, и так. Вариант с picture лишает этого.
4) Хм… вроде бы уже писал. Есть более 10 (или давайте более 100, если мало — более 1000) картинок. Нужно к каждой из них добавить вариант с точностью x6. Вы предлагаете вручную каждой из них дописывать source, причём не давая альтернатив. Если использовать picture.
5) Просто. Картинки бывают разными. Сама картинка (одна) — вполне семантична. Но вот беда, вы же предлагаете. что одна картика — то не одна картинка, это куча картинок, которые притворяются одной. И где тут семантичность?
>Любой браузер игнорирует неизвестные теги и атрибуты…
Кхм. Ну да. Верно. Похоже, что тут проблем с браузерами не будет. Зато с редакторами кода — будут.
>это не изменение оформления и не семантика. это контент. для больших экранов больше контента, для маленьких меньше.
В том то и дело, что это НЕ контент, а оформление. контент — это только первоначальная картинка А её варианты — уже оформление. Вы же не будете утверждать. что картинки по смыслу должны быть абсолютно разными для разных экранов? Они должны быть похожими, но адаптированными. А раз похожими — значит они производные от первоначальной и сиё должно быть автоматизированно. При этом, если человек захочет, то он должен иместь возможность сделать и так, и так. Вариант с picture лишает этого.
Могу даже свой концепт-вариант предложить. Не идеальный конечно и упрощённый, но думаю, что мою мысль насчёт css-решения продемонстрирует.
концепт-вариант flex-css alpha
retina_x? — определяется браузером. Возможно, правильнее это делать через медиа-запросы а не так как в этом примере.
См. пример-2
<img class="fleximg" src="{{$pic-dir}}/pic.png" />
<div class="pic_div"><div>
.fleximg {
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}
.fleximg retina_x2 {
media-src-type:inherit;
media-src-flex-add:'x2';
/*теперь ссылка ведёт на "{{$pic-dir}}/pic.x2.png"*/
}
.fleximg retina_x3 {
media-src-type:svg;
media-src-flex-add:'x3';
/*теперь ссылка ведёт на "{{$pic-dir}}/pic.x3.svg"*/
}
.fleximg retina_x4 {
/*ссылка по-умолчанию, ведёт на "{{$pic-dir}}/pic.png"*/
}
.pic_dir {
background-image: url(img/bg.jpg);
}
.pic_dir retina_x2{
media-src-type:svg;
media-src-flex-add:'x2';
/*теперь ссылка ведёт на "img/bg.x2.svg"*/
}
.pic_dir retina_x3{
media-min-width-cut: 900px; /*Изображение будет порезано*/
background-image: url(img/bg-full.bmp);
}
retina_x? — определяется браузером. Возможно, правильнее это делать через медиа-запросы а не так как в этом примере.
См. пример-2
концепт-вариант flex-css alpha-2 media
<img class="fleximg" src="{{$pic-dir}}/pic.png" />
<div class="pic_div"><div>
@media all{
.fleximg {
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}
.pic_dir {
background-image: url(img/bg.jpg);
}
}
@media screen and (min-retina:2){
.fleximg {
media-src-type:inherit;
media-src-flex-add:'x2';
/*теперь ссылка ведёт на "{{$pic-dir}}/pic.x2.png"*/
}
.pic_dir {
media-src-type:svg;
media-src-flex-add:'x2';
/*теперь ссылка ведёт на "img/bg.x2.svg"*/
}
}
@media screen and (min-retina:3){
.fleximg {
media-src-type:svg;
media-src-flex-add:'x3';
/*теперь ссылка ведёт на "{{$pic-dir}}/pic.x3.svg"*/
}
.pic_dir {
media-min-width-cut: 900px; /*Изображение будет порезано*/
background-image: url(img/bg-full.bmp);
}
}
@media screen and (min-retina:4){
.fleximg {
/*ссылка по-умолчанию, ведёт на "{{$pic-dir}}/pic.png"*/
}
.pic_dir {
/*ссылка по-умолчанию, ведёт на "img/bg.jpg"*/
}
}
CSS инструмент для создания внешнего вида, а вы через него формируете результирующий URL. «Уже сейчас видно, что все это будет глючить и тормозить» (с)
Опять же, убираем файл CSS и вся адаптивность валиться к чертям и в тег style это не положишь. Схема именования жестко закреплена, это очень плохо на мой взгляд.
Опять же, убираем файл CSS и вся адаптивность валиться к чертям и в тег style это не положишь. Схема именования жестко закреплена, это очень плохо на мой взгляд.
Адаптивность в большинстве случаев и так валится, если не удаётся загрузить css. Да и что мешает это записать в style — не совсем понятно.
Вроде бы позиционировалась концепция семантического HTML5. Так вот, picture — ни разу не семантичен. Предлагаемый мною вариант, конечно не идеален, но — семантичен.
>CSS инструмент для создания внешнего вида…
Именно. Так и дайте ему отвечать за внешний вид. Ведь picture делает именно это. Насколько я понимаю, picture не должен менять содержимое, а только внешний вид — это прямая задача css. как вы и пишите.
Вроде бы позиционировалась концепция семантического HTML5. Так вот, picture — ни разу не семантичен. Предлагаемый мною вариант, конечно не идеален, но — семантичен.
>CSS инструмент для создания внешнего вида…
Именно. Так и дайте ему отвечать за внешний вид. Ведь picture делает именно это. Насколько я понимаю, picture не должен менять содержимое, а только внешний вид — это прямая задача css. как вы и пишите.
Кажется вы застряли в 98. Тег
img для оформления уже давно давно не используется.Я вот захожу (к примеру) на opera.com/ru/computer и вижу, что там img используется как элемены дизайна, т.е. как оформление. Я имею ввиду скруглённые картинки. Они не несут информацию сами по себе, иллстрируя текст. Да, их можно назвать частью контента. а можно — оформлением. И правы будут оба.
Но вы ведь не об этом. Оформление сейчас достигается за счёт css так что ваш довод
>Опять же, убираем файл CSS и вся адаптивность валиться к чертям…
Справедлив именно для современных сайтов. И для любого css, а вот к img отношения не имеет.
Или (если брать мой концепт) — имеет в той же мере, что и всё остальное оформление.
А современный сайт без оформления… там не нужен контент. И не важно — адаптивный или нет.
Так что, если css отваливается — поздно пить баржоми.
Но вы ведь не об этом. Оформление сейчас достигается за счёт css так что ваш довод
>Опять же, убираем файл CSS и вся адаптивность валиться к чертям…
Справедлив именно для современных сайтов. И для любого css, а вот к img отношения не имеет.
Или (если брать мой концепт) — имеет в той же мере, что и всё остальное оформление.
А современный сайт без оформления… там не нужен контент. И не важно — адаптивный или нет.
Так что, если css отваливается — поздно пить баржоми.
Это чистый контент. Тут даже обсуждать нечего.
Это не совсем чистый контент, т.к. никакой информации он не несёт. Это скорее — дизайн статьи, оформление контента и т.п. Но всё это неважно.
Важно то, что на той странице изображений достаточно много. что бы начать себя чувствовать дискомфортно, когда потребуется у всех них добавить альтернативную плотность. А ведь это только одна страница. На сайте же изображений удет гораздо больше. Отсюда и числа 100 или 1000. Если это делать через css — да даже код страницы менять бы не пришлось, максимум — класс добавить, да и то не факт.
А с picture — придётся. а когда появится новая плотность — придётся ещё раз. А потом ещё. И выгоды в этом ни на грош.
Важно то, что на той странице изображений достаточно много. что бы начать себя чувствовать дискомфортно, когда потребуется у всех них добавить альтернативную плотность. А ведь это только одна страница. На сайте же изображений удет гораздо больше. Отсюда и числа 100 или 1000. Если это делать через css — да даже код страницы менять бы не пришлось, максимум — класс добавить, да и то не факт.
А с picture — придётся. а когда появится новая плотность — придётся ещё раз. А потом ещё. И выгоды в этом ни на грош.
В атрибут style ваши медиавыражения нельзя засунуть. Никак.
Я показал два концепта. Два. media лишь в одном.
Да, вариант с media мне кажется предпочтительней.
И да, в этом случае контент таки будет — будет картинка по умолчанию. Да, не адаптивный.
Но если отвалился весь css, а адаптивность оформления обеспечивалась за счёт него (бутстар, 960 и т.п.), то неадаптивность картинки роли не сыграет.
Да, вариант с media мне кажется предпочтительней.
И да, в этом случае контент таки будет — будет картинка по умолчанию. Да, не адаптивный.
Но если отвалился весь css, а адаптивность оформления обеспечивалась за счёт него (бутстар, 960 и т.п.), то неадаптивность картинки роли не сыграет.
Адаптивность разная бывает. Цветная картинка, которая подменяется ч/б для печати это тоже адаптивность.
И именно это часто делают через css media print
Разве не так? А picture загоняет всё в код страницы. И где тут вы видите семантичность?
Разве не так? А picture загоняет всё в код страницы. И где тут вы видите семантичность?
как вы будете подменять урл фотографии через CSS?
Хотя бы также как и фон.
Можно так как предложил я. На мой взгляд, самое удобное — это дать возможность автоматически дополнять URL. Неважно каким способом. Я предложил генерировать postfix или prefix — вам не понравилось, но это — реальное улучшение. Я не настаиваю на этом способе, но хочу показать удобство идеи автоматизирования ссылок (или её аналогов).
Можно так как предложил я. На мой взгляд, самое удобное — это дать возможность автоматически дополнять URL. Неважно каким способом. Я предложил генерировать postfix или prefix — вам не понравилось, но это — реальное улучшение. Я не настаиваю на этом способе, но хочу показать удобство идеи автоматизирования ссылок (или её аналогов).
>Схема именования жестко закреплена, это очень плохо на мой взгляд.
А это в моём варианте обсуждаемо и подлежит изменению. Можно продумать несколько вариантов. тот вариаент что я написал — даёт возможность быстро вставить 1000 картинок. А если 1001-ой он не подходит — поставить ей другой класс.
>…а вы через него формируете результирующий URL
Он так и так должен формироваться разный. Просто я предлагаю более гибкий вариант. Пусть и не проработанный.
Вы можете для наглядности сравнить объём кода и понять, что… Упс, не можете. Извините. Ведь Picture по позволит менять background. т.е. у picture заведомо ограничена область применения.
А это в моём варианте обсуждаемо и подлежит изменению. Можно продумать несколько вариантов. тот вариаент что я написал — даёт возможность быстро вставить 1000 картинок. А если 1001-ой он не подходит — поставить ей другой класс.
>…а вы через него формируете результирующий URL
Он так и так должен формироваться разный. Просто я предлагаю более гибкий вариант. Пусть и не проработанный.
Вы можете для наглядности сравнить объём кода и понять, что… Упс, не можете. Извините. Ведь Picture по позволит менять background. т.е. у picture заведомо ограничена область применения.
Только что нашел статью от 22 сентября, в которой приводится аргументация против использования
<picture>
Я лучше останусь с img.
Вот я не понимаю почему не сделают подстановку переменных на этапе конструкции DOM? Все костыли какие-то с тонной JS и новые конструкции в HTML, прицеленные на узкий кейз. ОК, а если я не картинку хочу а фон с разными DPI и кропом? Чего стоит на этапе парсинга сразу разворачивать какие-нибудь ${DPI-X} и ${DPI-Y}, ${SCREEN-WIDTH} и прочее и подставлять в URL или в HTTP хедеры. И эту, и еще миллион проблем с тем же видео решили бы сразу.
А есть какие-то явные критерии или рекомендации, что браузер должен считать двукратной и трехкратной плотностью пикселей?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Picture — новый элемент, которого нет