LINUX.ORG.RU

Картинки, data-URI, множественное их использование в одном html.


1

1

У меня есть картинки, которые много раз используются в разных местах одного html. Беда в том, что я хочу картинки включать с использованием data URI и включать их каждый раз в месте использования получается неэффективно с точки зрения размера, да и технически сложно: картинки хочется включить где-нибудь в конце документа в невидимом div и потом как-то использовать ссылаясь на них (это просто сделать потому что).

Практически я сейчас вынужден делать, например, такую вещь. Вставлять картинки как <img src=«#idxxx» class=«autoimg» attributes> в местах использования и один раз в конце как <img id=«idxxx» src=«data:....»> Потом, после загрузки документа, делать document.getElementsByClass(«autoimg») и для каждой такой картинки вставлять вместо неё ту, что с id=«idxxx», а атрибуты брать из той, где src=«#idxxx», последнюю потом удалять. Но у меня ещё картинки нужны в CSS. Можно такую замену сделать в CSS но уже неудобно. А ведь стили ещё могут быть в атрибутах элементов... совсем неудобно. Картинки в стилях нужны для смены картинки при :hover и :active.

Может это можно сделать как-то иначе? Вообще задача множественного использования какого-либо ресурса в программировании типичная же. А в html как-то неудобно получается, каждый раз заново одно и то же загружать...

Пока писал, подумал — можно загрузить так одну картинку (через data URI) и использовать т.н. CSS-спрайты примерно таким образом: в нужном месте вставляется <object id=«name»></object> и для него пишется стиль (хоть в атрибутах, хоть в <style>), что у него background-image: url(image.png) ... И тут образуется ещё один лишний файл. Неудобно, не будем развивать holywar почему.

Можно data URI применить так: в CSS делаются отдельные классы, для которых пишется background-image: url(data:...), и применить в зависимости от нужных картинок классы к нужным элементам. Вроде, это хорошее решение.

Может кто подскажет что-то ещё?

Eщё хотел спросить вдогонку. Мне в html нужно включить (опять же, не отдельным файлом) SVG или ещё что-нибудь такое. Проблема в том, что браузер пытается его отображать сразу. А отображать мне не нужно. Мне для использования в стилях, например (через url(#id), здесь, в отличии от картинок, по id можно почему-то, а картинки требуют только файла). И в неотображаемый div положить нельзя — не будет работать. Приходится делать position fixed, вне экрана и в нижнем слое, например. Как включать «неотображаемые» элементы в html? Понятно, что после загрузки на javascript там что угодно сделать можно. Но хочется меньше программировать то, что можно не программировать.


Вообще задача множественного использования какого-либо ресурса в программировании типичная же. А в html как-то неудобно получается, каждый раз заново одно и то же загружать...

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

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

Reaper ★★
()
Ответ на: комментарий от Reaper

Не согласен. Когда говорят «не кеширует» обычно подразумевают, что у них html динамически сгенерированный и/или с параметрами (GET) и потому не кешируется. В данном случае никакой динамики на сервере нет и html со всеми картинками внутри прекрасно закешируется.

Потом речь идёт вообще о web application. Там загружаться каждый раз вообще ничего не должно. Только однократно, потом для обновления. Но тут не всё так просто. Фактически эта технология, с cache manifest, сырая, плохо поддерживается, браузеры имеют разные ошибки. И разводить внутри неё массу файлов чревато следующим: в кеше масса старых файлов, браузер (конкретно андроид 2.3, например, и их уже продано и никто менять ничего не будет) их обновлять не хочет, думай как их оттуда вычистить... И не только это. Собственно загрузка контента она не обязательно из веб-сервера осуществляться может. Потому, что web application может быть завёрнут в нативное приложение для телефона, например. И там html можно получать либо через file, либо вовсе каким-то иным образом, когда даже понятия файл не будет. Это было бы удобно, чтоб всё было внутри одного html. В том числе и по такой причине, что можно сделать такую вещь: разбить приложение на 2 файла. Первая часть: загрузчик. Он пишется 1 раз, он примитивен и не содержит чего-то требующего обновления. Эта часть или помещается в кэш браузера (через cache manifest), либо каждый раз загружается через GPRS. Благо она маленькая весьма. И вторая часть — html внутри которого всё. Эта часть может храниться внутри браузера (вместо того, чтобы полагаться на его кэш) внутри localStorage, например, или даже внутри куков будучи попиленная на 4кбайт кусочки. И в этом большой профит: кэшироваться начинает даже у тех, у кого поддержки cache manifest нет (по крайней мере основная большая часть) и нет никаких проблем с обновлением (свой код, который таки можно отладить чтоб работал).

Собственно с сервером общение через JSONP и это отдельная история. Никаких ссылок, ресурсов, скриптов на сервере с динамическим контентом, ничего нет. Пока и общения с сервером нет (задача приложения — отправлять и принимать смски...)

fk0
() автор топика

Не нужно этого хотеть.

>Может это можно сделать как-то иначе? Вообще задача множественного использования какого-либо ресурса в программировании типичная же. А в html как-то неудобно получается, каждый раз заново одно и то же загружать...

Назло маме отморзил уши, а виноват HTML, лол. Осиль CSS спрайты, если тебя волнует именно этот вопрос.

anonymous
()
Ответ на: комментарий от fk0

>Не согласен. Когда говорят «не кеширует» обычно подразумевают, что у них html динамически сгенерированный и/или с параметрами (GET) и потому не кешируется. В данном случае никакой динамики на сервере нет и html со всеми картинками внутри прекрасно закешируется.

У тебя каша в голове.

anonymous
()
Ответ на: комментарий от fk0

Лучше сам забанься, весь вебдев раком засрал. Кури маны.

anonymous
()

или даже внутри куков будучи попиленная на 4кбайт кусочки

убей себя

В чем смысл этого яростного велосипедства, которое ты здесь описываешь?

special-k ★★★★
()
Ответ на: комментарий от fk0

Забаньте уже товарища неосилятора. Даже файлы не осилил человек.

anonymous
()
Ответ на: комментарий от Kalashnikov

Чего освоить? Я уже сделал и надо сказать, это хорошее решение. Позволяет упхнуть картинки в один файл с html, позволяет ссылаться на картинку по имени класса и использовать её таким образом множество раз. И это хорошо, что через классы, потому, что имя картинки теперь не прибито гвоздями к исходникам или к html и его можно через CSS менять, например. Картинки, понятно, для оформления только.

fk0
() автор топика
Ответ на: комментарий от fk0

Если понадобиться для классического веб-сайта, то css с картинками можно отдельным файлом сделать и всё. И таки да, он с миллионом маленьких картинок ещё загружаться будет быстрей, несмотрея на все base64, чем миллион http запросов за каждой. Особенно через GPRS.

fk0
() автор топика
Ответ на: комментарий от fk0

Со спрайтами же неудобно что нужен таки отдельный файл графический. Со спрайтами нельзя часть картинок сделать анимированными. Со спрайтами нужна какая-то тулза для генерирования смещений в картинке (это вообще непонятно как сделать, хоть через image map, неудобно короче — я имею ввиду, чтоб в исходниках писать «картинка цветочек-в-горшочке» вместо sprite.gif 123 456).

fk0
() автор топика
Ответ на: комментарий от fk0

Да и эти 123 456 — их у дизайнера, который картинки рисует, тоже не должно быть, он же рехнётся, ему тоже нужен цветочек-в-горшочке...

fk0
() автор топика
Ответ на: комментарий от fk0

с миллионом маленьких картинок

Никто не будет заходить на этот ужас. И в любом случае: зачем сразу грузить миллион превьюшек фото? Все равно их за раз не просмотришь. Лучше на группы штук по 20 поделить.

Eddy_Em ☆☆☆☆☆
()

Вроде, это хорошее решение.

Так что тебе еще надо?

Как включать «неотображаемые» элементы в html?

Все что находится в body и может быть отображено - отображается. Вывод: помещай такие элементы за пределами body, а потом переноси по надобности при помощи js.

jamy
()
Ответ на: комментарий от Kalashnikov

Как сделать спрайты? Тех. требования: программист работает с именем изображения, а не с координатами. Дизайнер тоже работает с именем. Допустим, дизайнер имеет отдельный файл на каждую картинку. Их, следовательно, нужно объединить в одну. И при этом в отдельный файлик (например, CSS) записать координаты, размеры и имена каждой картинки. Уже проще, понятно, что нужно сделать. Но чем? Есть такая задача «оптимальной укладки рюкзака»... Уже нетривиально. Картинки (каждая) естесственно разных размеров.

И в любом случае это не годится: нет анимации, нет возможности «безфайловой» работы. Чисто технические причины. У data-uri решения это всё есть. И более того, можно смешивать jpeg и gif добиваясь оптимального качества и размера. А со спрайтами понятно. Или пиксель арт, или jpeg, но не то и другое сразу. Или разные спрайты. В пределе — разные картинки через <img> и не морочим мозг.

fk0
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.