Комментарии 19
С элементом picture какая-то дичь. Ввел значит его вордпресс почти самым первым в свой стандарт тем. И из-за этой херни пошло дикое раздувания обьема места, ведь даже в примере
srcset=«medium.jpg 500w, large.jpg 800w» внезапно нужно сделать делает две копии файла. А для чего? Экономии трафика? Повернул я, значит телефон — получил случайно подгрузку новых более широких файлов? Вместо одной копии — две. Ладно, маловероятно. Окей, разумно там при больших пропорциях это делать, но я не видел ни одной статьи с попыткой определить как же выставлять грамотно эти размеры. Если открыть medium, то там используется srcset но как-то внятно чтоли, судя по тому что они как то не сильно жмут картинки — как-то это не понятен в чем выигрышь в сумме.
Или, значит, уходили от инлайн стилей а тут на тебе
Мне казалось галочка «печатать фоновые изображения» в диалоговом окне печати решает этот вопрос.
srcset=«medium.jpg 500w, large.jpg 800w» внезапно нужно сделать делает две копии файла. А для чего? Экономии трафика? Повернул я, значит телефон — получил случайно подгрузку новых более широких файлов? Вместо одной копии — две. Ладно, маловероятно. Окей, разумно там при больших пропорциях это делать, но я не видел ни одной статьи с попыткой определить как же выставлять грамотно эти размеры. Если открыть medium, то там используется srcset но как-то внятно чтоли, судя по тому что они как то не сильно жмут картинки — как-то это не понятен в чем выигрышь в сумме.
Или, значит, уходили от инлайн стилей а тут на тебе
<source media="(min-width: 1350px)"пиши атрибуты, к тому же, покажите мне этот кейс, где адаптивный логотип зависит от ширины экрана, а не от ширины элементов ряду. Остальные элементы как управляются? Не инлайново? Ну так и логом инлайново никто и не будет управлять. Управление поведением одинаковых элементов должно быть в одном месте — css или шаблон — кому как удобнее.
Постарайтесь не включать в страницы, предназначенные для печати, изображения, выводимые с помощью CSS-свойства background
Мне казалось галочка «печатать фоновые изображения» в диалоговом окне печати решает этот вопрос.
<picture> предназначен для вывода разных изображений в зависимости от физического размера экрана (так называемый art direction). Допустим у вас есть картина «корова на лугу». Такая средних размеров корова на фоне большого прекрасного луга. На больших десктопных экранах можно показать картину целиком. Масштабирование для небольших экранов делает корову слишком мелкой и пользователь видит в основном только лужайку. Кому-то приходит идея обрезать картинку так, чтобы корова занимала большую часть картины, пожертвовав частью луга. Для совсем маленьких экранов можно оставить вообще лишь коровью морду. Или нет? В общем, это процесс творческий, плохо поддающийся алгоритмизации. Поэтому если вам нужен качественный результат, то работу выполняет дизайнер. Так появляется вторая, третья и так далее версии картины. Верстальщику остается лишь упаковать все варианты в <picure>.
Основное назначение <img srcset> — предоставить версии одной и той же картинки для экранов с разной плотностью пикселей. Появился примерно вместе с retina экранами. Плотность пикселей на дюйм, принятая за базовую в вебе — 96 dpi. x2 это 192, x4 384 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.
Основное назначение <img srcset> — предоставить версии одной и той же картинки для экранов с разной плотностью пикселей. Появился примерно вместе с retina экранами. Плотность пикселей на дюйм, принятая за базовую в вебе — 96 dpi. x2 это 192, x4 384 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.
Здесь хорошо то, что фоновый цвет выведется только в том случае, если не удастся загрузить изображение. Это нас устроит.
На самом деле фоновый цвет выводится всегда, так что не устроит: https://jsfiddle.net/hzmLqtve/
1. Атрибут alt тэга img не используют еще поисковики? вроде как для СЕО хорошо и хорошо если alt уникален.
2. Как бэкенщик устал от SVG в во вьюхах, пытаюсь как-то в отдельные файлы и т.д. но реально бесят, увеличивают знатно код по высоте. А главное зачем? Бывают исключения, но такие редкие и специфичные, и :hover не из их числа, как по мне.
3. Могу ошибаться, но очень большое пожелание помнить фронту, что такое элемент дизайна/интерфейса, а что контента! Если завтра захотят изменить дизайн, то это картинка останется?
Если нет, то по возможности отставлять ее в CSS бэграундами и т.д. чтоб потом и бэк под это хозяйство не переделывать. Логотоп сайта наверно единственное что можно оставить помимо основных изображений контенте (фото новостей и т.д.)
Даже если требует анимации на hover, все равно пытаться там (в CSS) оставить всеми способами, лучше 2-3 разные картинки заюзать в CSS, чем в код страницы сувать. Тем более CSS закэшируется, а страницы качаются всегда полные. Особенно с SVG
2. Как бэкенщик устал от SVG в во вьюхах, пытаюсь как-то в отдельные файлы и т.д. но реально бесят, увеличивают знатно код по высоте. А главное зачем? Бывают исключения, но такие редкие и специфичные, и :hover не из их числа, как по мне.
3. Могу ошибаться, но очень большое пожелание помнить фронту, что такое элемент дизайна/интерфейса, а что контента! Если завтра захотят изменить дизайн, то это картинка останется?
Если нет, то по возможности отставлять ее в CSS бэграундами и т.д. чтоб потом и бэк под это хозяйство не переделывать. Логотоп сайта наверно единственное что можно оставить помимо основных изображений контенте (фото новостей и т.д.)
Даже если требует анимации на hover, все равно пытаться там (в CSS) оставить всеми способами, лучше 2-3 разные картинки заюзать в CSS, чем в код страницы сувать. Тем более CSS закэшируется, а страницы качаются всегда полные. Особенно с SVG
2) Используйте symbol & use
а какие есть задачи или плюсы, когда нет много JS-работы с SVG (что кстати крайне редко в быту), чтоб SVG было в html?
зато вроде простая задача: заменить кнопку с надписью «удалить» на иконку корзины с ховером. Молодой верстальщик сверстал ссылку, в которой SVG или IMG на SVG. Таких кнопкой по проекту больше N-сот, на что бэкенщик начинает ворчать и учить, что: 1. Действие только по кнопкам 2. Мне твою… SVG по всем проекту бегать менять?) Ок. переделали, кнопку по готовому классу покрыли стилями заменили на вид ссылки с иконкой, и тут разумеется вопрос, а на кой вообще svg в HTML? легче делать так? завтра нужно будет поменять эту иконку и кто-то будет знатно ворчать? я бы не давал столько прав фронту перековыривать бэк по каким-то простым причинам… даже если заюзать «symbol & use», все равно на кой SVG в HTML?
зато вроде простая задача: заменить кнопку с надписью «удалить» на иконку корзины с ховером. Молодой верстальщик сверстал ссылку, в которой SVG или IMG на SVG. Таких кнопкой по проекту больше N-сот, на что бэкенщик начинает ворчать и учить, что: 1. Действие только по кнопкам 2. Мне твою… SVG по всем проекту бегать менять?) Ок. переделали, кнопку по готовому классу покрыли стилями заменили на вид ссылки с иконкой, и тут разумеется вопрос, а на кой вообще svg в HTML? легче делать так? завтра нужно будет поменять эту иконку и кто-то будет знатно ворчать? я бы не давал столько прав фронту перековыривать бэк по каким-то простым причинам… даже если заюзать «symbol & use», все равно на кой SVG в HTML?
Не отжирает запрос, весит меньше (при передаче файла в довесок идут ещё и заголовки, а svg часто весят сущие байты). Инлайнят или в спрайты всякие мелкие картинки собирают ровно по тем же причинам. Никто не мешает собрать все SVG в один «спрайт» и использовать символы уже из него.
1. Свежий http как бы решает проблемы с кучами запросами, да и в CSS можно закинуть как data, как вариант отдельные файлы styles.css и svg-files.css
2. Если «спрайт.css» из набора svg внутри, тогда согласен
3. Вся статика не только в кэш идет, но и отдается под разным gz, br и т.д. сжатием
Есть еще что-то? Только не подумайте что придираюсь, я правда интересуюсь этим вопросом)
2. Если «спрайт.css» из набора svg внутри, тогда согласен
3. Вся статика не только в кэш идет, но и отдается под разным gz, br и т.д. сжатием
Есть еще что-то? Только не подумайте что придираюсь, я правда интересуюсь этим вопросом)
В статье упущена часть про правильную компрессию и форматы зображений и хотя бы грубый пример нарезания на разные размеры.
Она не то чтобы упущена — автор просто не в курсе. ВСЕ картинки в статье тупо PNG. Самая тяжёлая — с россыпью круглых фото-аватарок. Даже при небольшой JPEG-компрессии (90% качества) файл худеет в 4 раза. Спасибо хоть, что не в BMP (попадаются и такие уникумы). Тут в соседней статье бьются за размеры JS-фреймворков, а подобные авторы лёгким движением перечёркивают все старания, с лихвой перекрывая их трафиком от неоптимизированных фоточек.
Наверное я не получу ответ на этот вопрос. Но самый ваш первый пункт, где вы выставляете размер изображения в инлайн html стиль, это единственная тема, которую стоит обсуждать. И эту тему достаточно хорошо не обсудил никто в интернете (или я ещё не видел, посоветуйте). Что если у вас не просто 2 картинки, не просто логотип. Что если у вас огромный сайт с резиновыми картинками всех видов и размеров. И что если в одной и той же секции картинка на разных интервалах 300px<600px — резиновая, 601px<900px — статичная и.т.д Как это контролировать? Ответ: Никак. Вот вышла бы статья у вас, а не читать про picture в 32 раз в жизни. Но в закладки добавлю, ибо я аутист и забуду всё через пару дней.
Есть только 1 вариант, написать sass функцию, которая будет генерировать 1920 медиа выражений, я извиняюсь, скоро 9к мониторы появятся, т.е. 10 тыс медиа выражений
Зачем SASS? Зачем «10 тыс медиа выражений»? Если вы хотите отловить такие шаги, то логичнее задать поведение функцией, а не таблицей (CSS — это таблицы — Cascading Style Sheets). Пишите JS.
Браузер не может знать о том какого размера придёт изображение и если вы делаете какую-то cms, где контент заведомо бывает всех размеров, эта проблема моментально возникает. Чтобы сделать lazy load, browser должен получать какой-то конфиг с тем какого размера на этой странице будут изображения ещё до того как пошёл на какой-то сервер за этими изображениями. И только в этом случае получится что он будет знать какого точно размера конкретная картинка на конкретном разрешении. Object fit и все остальные youtube хаки типа padding-bottom, никак не помогают решить проблему того что контент будет прыгать.
единственное что можно сделать — использовать «тильда вёртску», когда у вас всё на position: absolute, и когда все изображения на сайте больше определённой высоты будут обрезаться
Чем вам вариант
Напишите наТостерQNA. Мне кажется, что на конкретном примере было бы удобнее.
object-fit: scale-downНапишите на
Для добавления внутренней границы аватару, можно тегу img задать внутренний box-shadow.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
[в закладки] Работа с изображениями в веб