Комментарии 87
НЛО прилетело и опубликовало эту надпись здесь
Если сделаете онлайн сервис для конвертации — цены вам не будет :)
Честно говоря, не знаком с этой технологией и из описания не понял существенных плюсов и технологии применения.
Поясните как для чайника, в чем плюс в отличии от обычных изображений и в чем заключается технология, в обработке каждой закачиваемой картинки?
Поясните как для чайника, в чем плюс в отличии от обычных изображений и в чем заключается технология, в обработке каждой закачиваемой картинки?
Один http запрос за большим css файлом с внедренными картинками, нежели много запросов за кучей мелких картинок.
а не проще все изображения (в особенности одного размера) поместить в одну картинку-полоску и через css обращаться к какждой картинки из этой полоски (забыл как это называется)?
спрайты называется, вопрос в автоматизации сбора такой картинки и пересбора при изменениях
Автор попросил передать Вам ответ:
если все файлы забить в css sprite то невозможна тонкая оптимизация изображений, допустим по палитре
пока не загрузится вся картинка, будет ощущение что сайт не загрузился до конца, эффект пропадет
почитайте на webo.in про это, или посты sunnybear
почитайте на webo.in про это, или посты sunnybear
> Один http запрос за большим css файлом с внедренными картинками, нежели много запросов за кучей мелких картинок.
А пепревешивает ли выигрыш от этого ту проблему, что объём в Base64 больше чем исходный?
А пепревешивает ли выигрыш от этого ту проблему, что объём в Base64 больше чем исходный?
Base64 + Gzip ~ src
Предполагаю, что если статику отдает не nginx, то выигрыш от уменьшения числа соединений есть.
Но я не эксперт, точно не знаю.
Если речь о 20-30 картинках, то можно вообще не заморачиваться я думаю. Разница заметна на нескольких сотнях (богатые интерфейсы, онлайн приложения, игры).
Но я не эксперт, точно не знаю.
Если речь о 20-30 картинках, то можно вообще не заморачиваться я думаю. Разница заметна на нескольких сотнях (богатые интерфейсы, онлайн приложения, игры).
вот вам статьи на тему duris.ru/articles/ с детальным обзором, зачем и почему.
> т.к. приходилось 1 файл передавать два раза — раз для IE, в mhtml, и второй для всех остальных, в data uri
а почему передавать два раза? один раз для ИЕ, и один раз раз для всех остальных. если правильно подключать — совместная передача не происходит. Попробуйте duris.ru, там реализован механизм подключения только того что нужно.
а вообще статья отлично расписывает возможности объединения файлов, думаю пригодится.
а почему передавать два раза? один раз для ИЕ, и один раз раз для всех остальных. если правильно подключать — совместная передача не происходит. Попробуйте duris.ru, там реализован механизм подключения только того что нужно.
а вообще статья отлично расписывает возможности объединения файлов, думаю пригодится.
кстати, а может стоит разделить css файл на две части, отдельно css без data:uri и отдельно css mix data:uri + mhtml, тогда будет возможность прогнать первую часть через css компрессор да и не надо будет писать постоянно Content-Type: text/css;
и было клево с PNG сделать без предварительного прогона через optipng.
Спасибо за исследования! очень редко такие статьи стали появляться.
и было клево с PNG сделать без предварительного прогона через optipng.
Спасибо за исследования! очень редко такие статьи стали появляться.
А как называется этот интересный шрифт у Вас на схемках?
В IE8 НЕ работает
В IE7 работает
В IE7 работает
засада, подтверждаю в ИЕ8 не работает
Автор попросил ответить:
файлы из архива и сайт по ссылке не отрабатывали в IE8 потому что хак, который я использовал в css работает только с <IE7. Сейчас на сайте включен режим эмуляции IE7 и все нормально отрабатывает. Для более изящного решения нужен другой css хак.
img215.imageshack.us/img215/5381/201004122229181680x1050.png
это пруфскрин
И ещё чуть-чуть:
можно и без дуриса, просто через .htaccess передавать файл с одним mhtml для ie и с datauri для всех остальных. сейчас для ie передается не gzip'нутый css, а для остальных gzip'нутый. Без optipng можно, но для этого поля в png файле должны быть выставленны в правильном порядке (в таком, в каком их понимает мой скрипт), а optipng это просто удобно. Но никто не мешает написать свой скрипт\улучшить сцществующий. Мои скрипты лишь пример реализации.
Хм… Технология, возможно, хороша, но намного ли это будет быстрей CSS спрайтов со внешней картинкой? Да, со спрайтами на один HTTP запрос больше, но стоит ли этот один запрос такого усложнения цикла разработки сервиса?
Ведь на странице у вас в любом случае будут картинки помимо закодированных — фотографии, иллюстрации к статьям или портфолио и т.п. Да и на любом мало-мальски серьезном проекте всегда есть что усовершенствовать помимо data:URI.
В общем, вопрос в чем: адекватны ли затрачиваемые усилия достигаемому результату?
Ведь на странице у вас в любом случае будут картинки помимо закодированных — фотографии, иллюстрации к статьям или портфолио и т.п. Да и на любом мало-мальски серьезном проекте всегда есть что усовершенствовать помимо data:URI.
В общем, вопрос в чем: адекватны ли затрачиваемые усилия достигаемому результату?
вопрос в полной автоматизации создания data:uri css sprites, что не реализуемо на 100% при обычных спрайтах.
Вопрос адекватности — не только в автоматизации.
Подобная оснастка усложняет цикл разработки, заставляет проводить дополнительное тестирование (удостовериться что со спрайтами все не поехало), усложняет отладку (т.к. финальные прогоны надо делать с уже «заспрайтованными» файлами, а там будет не очень-то человекопонятное CSS).
На больших проектах это достаточно сильно может увеличить трудоемкость, даже если будет автоматизировано.
Получится ли сопоставимый этому геморрою результат?
Подобная оснастка усложняет цикл разработки, заставляет проводить дополнительное тестирование (удостовериться что со спрайтами все не поехало), усложняет отладку (т.к. финальные прогоны надо делать с уже «заспрайтованными» файлами, а там будет не очень-то человекопонятное CSS).
На больших проектах это достаточно сильно может увеличить трудоемкость, даже если будет автоматизировано.
Получится ли сопоставимый этому геморрою результат?
все это (как и спрайты) полностью автоматизируется. Не зря же WEBO Site SpeedUp уже год успешно работает :)
А разве можно автоматизировать создание спрайтов? Там же все может быть очень сложно сделано.
может быть, а может и не быть.
Мы год назад эту задачу в 95% случаев решили. И только через полгода Steve Souders выкатил свой SpriteMe, который не все возможные случаи обсчитывает.
Мы год назад эту задачу в 95% случаев решили. И только через полгода Steve Souders выкатил свой SpriteMe, который не все возможные случаи обсчитывает.
Ну не знаю, что-то сомневаюсь я, бывают же когда ширина/высота в стилях прописана не в пикселах (или вообще не прописана), background-position не в пикселях, бывает определения раскиданы по разным селекторам, бывает для ИЕ отдельные правила.
А банальные определения типа height: 20px, width: 20px, backgound-position: 50% — это да, наверно автоматизируется.
А банальные определения типа height: 20px, width: 20px, backgound-position: 50% — это да, наверно автоматизируется.
получится, нужно просто иметь нормальное автоматизировано средство от геморной боли
в нормальной проекте все равно используется какой-то инструмент оптимизации. вызовом одного скрипта собирается весь оптимизированный билд.
в нормальной проекте все равно используется какой-то инструмент оптимизации. вызовом одного скрипта собирается весь оптимизированный билд.
В теории — да. Но на практике, как я понимаю, пока такого средства не только нет, но и сами даже выкладки существуют только в теории и никем серьезно на нормальном проекте не тестированы?
ошибаетесь — средство есть и в проектах нормальных используется, как примеры kinobaza.tv, ide.hivext.ru, www.dolcevilla.cz
интересно, каким образом duris к живому сайту прикручивался…
с помощью offline версии, кстати сейчас режим тестирования проводим, если есть достойный проект — могу сделать билд под него
для этого необходимо написать письмо на адрес duris.ru[гав]gmail.com (ну или мне в личку) с пометкой в теме «duris offline». В письме укажите следующие данные:
— язык программирования
— кратко опишите прицип работы и структуру проекта
— ссылка на online сайт проекта
обычные домашние страницы не рассматриваются, на данный момент отрабатываем под проекты средней и выше средней сложностей.
для этого необходимо написать письмо на адрес duris.ru[гав]gmail.com (ну или мне в личку) с пометкой в теме «duris offline». В письме укажите следующие данные:
— язык программирования
— кратко опишите прицип работы и структуру проекта
— ссылка на online сайт проекта
обычные домашние страницы не рассматриваются, на данный момент отрабатываем под проекты средней и выше средней сложностей.
намного. Просто поверьте :)
Ответ автора через моё посредничество:
сия технология не всеобъемлюща и не идеальна. через нее стоит пропускать лишь те изображения, которые встречаются на каждой странице(или просто часто). После написания скриптов процесс внедрения занимает ОЧЕНЬ мало времени.
С swf случайно не эксперементировали в MHTML?
Довелось поковыряться с внедрением swf для копирования текста со страницы в буфер обмена — flash-плагин не поддерживает data uri (на сайте Adobe было упоминание, что пока и не планируется добавление поддержки), а браузеры самостоятельно не преобразовуют данные перед передачей плагину, в итоге пришлось отказаться от этой затеи.
Довелось поковыряться с внедрением swf для копирования текста со страницы в буфер обмена — flash-плагин не поддерживает data uri (на сайте Adobe было упоминание, что пока и не планируется добавление поддержки), а браузеры самостоятельно не преобразовуют данные перед передачей плагину, в итоге пришлось отказаться от этой затеи.
Кстати, если кто-то хотел бы поделиться с автором статьи инвайтом — он был бы не против его получить. Пишите мне в личку, дам адрес электронной почты.
Мне кажется лучше не парится и отдавать ie6 и ie7 сами изображения:
body{background:url(data:image/png;base64,blablabla)}
* html body{background:url(../images/blablabla.png)}
*:first-child + html body{background:url(../images/blablabla.png)}
body{background:url(data:image/png;base64,blablabla)}
* html body{background:url(../images/blablabla.png)}
*:first-child + html body{background:url(../images/blablabla.png)}
Спасибо. Не знал раньше вообще что есть такая Data URI.
Помимо указанного применения с интеграцией графики в CSS сразу вырисовываются такие применения:
Написать сохранялку страниц, которая будет брать любую открытую в браузере страницу и давать на выходе один стандартный html-файл, внедряя внутрь него и CSS и JS и теперь ещё графику. Раньше такое уже было в MHT, но теперь есть возможность делать стандартный HTML.
Внедрять картинки в почтовые и др. сообщения не ввиде ссылок и не ввиде приложений, а прямо так. Кстати интересно, у кого карма положительная и теги можно использовать, попробуйте-ка в теге IMG в комменте так картинку вставить?
Помимо указанного применения с интеграцией графики в CSS сразу вырисовываются такие применения:
Написать сохранялку страниц, которая будет брать любую открытую в браузере страницу и давать на выходе один стандартный html-файл, внедряя внутрь него и CSS и JS и теперь ещё графику. Раньше такое уже было в MHT, но теперь есть возможность делать стандартный HTML.
Внедрять картинки в почтовые и др. сообщения не ввиде ссылок и не ввиде приложений, а прямо так. Кстати интересно, у кого карма положительная и теги можно использовать, попробуйте-ка в теге IMG в комменте так картинку вставить?
Вот:
>> Раньше такое уже было в MHT, но теперь есть возможность делать стандартный HTML
Есть пара небольших препятствий:
1. В rfc говорится:
«A new URL scheme, „data“, is defined. It allows inclusion of small data items...» —
насколько «небольшие» элементы — не оговаривается. К примеру, в MSIE максимальный размер — 32,768 символа. Т. е. могут быть проблемы с совместимостью, особенно если через data uri включены крупные файлы.
2. И снова MSIE: «For security reasons, data URIs are restricted to downloaded resources. Data URIs cannot be used for navigation, for scripting, or to populate frame or iframe elements.»
Т.е. попросту — так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.
Есть пара небольших препятствий:
1. В rfc говорится:
«A new URL scheme, „data“, is defined. It allows inclusion of small data items...» —
насколько «небольшие» элементы — не оговаривается. К примеру, в MSIE максимальный размер — 32,768 символа. Т. е. могут быть проблемы с совместимостью, особенно если через data uri включены крупные файлы.
2. И снова MSIE: «For security reasons, data URIs are restricted to downloaded resources. Data URIs cannot be used for navigation, for scripting, or to populate frame or iframe elements.»
Т.е. попросту — так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.
Ну да, и еёщ одно:
3. В rfc определяется следующий синтаксис:
dataurl := «data:» [ mediatype ] [ ";base64" ] "," data
Т.е. после данных не может идти ничего. Если вдруг понадобится передать параметры в data uri, то ничего не получится, т.е. конструкция вида:
window.open('data:text/html;charset=utf-8,%3C%21DOCTYPE%20html%3E...%0D%0A?param1=value1¶m2=value2','_blank','height=500,width=200');
работать, к сожалению, не будет.
3. В rfc определяется следующий синтаксис:
dataurl := «data:» [ mediatype ] [ ";base64" ] "," data
Т.е. после данных не может идти ничего. Если вдруг понадобится передать параметры в data uri, то ничего не получится, т.е. конструкция вида:
window.open('data:text/html;charset=utf-8,%3C%21DOCTYPE%20html%3E...%0D%0A?param1=value1¶m2=value2','_blank','height=500,width=200');
работать, к сожалению, не будет.
> максимальный размер — 32,768 символа
В общем случае должно прекрасно хватить.
> так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.
А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
В общем случае должно прекрасно хватить.
> так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.
А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
> В общем случае должно прекрасно хватить.
В общем случае — да (я потому и написал «небольших»), но если действительно сделать сохранение страниц в один файл, то могут быть проблемы с чтением сохранённого файла, если, к примеру, на странице присутсвуют большие картинки (проблемы скорее всего только в MSIE — проверю, отпишусь, самому интересно стало).
> А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
Не обязательно скрипты: содержимое iframe'ов, содержимое фреймов во frameset'е.
В общем случае — да (я потому и написал «небольших»), но если действительно сделать сохранение страниц в один файл, то могут быть проблемы с чтением сохранённого файла, если, к примеру, на странице присутсвуют большие картинки (проблемы скорее всего только в MSIE — проверю, отпишусь, самому интересно стало).
> А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
Не обязательно скрипты: содержимое iframe'ов, содержимое фреймов во frameset'е.
>> В общем случае должно прекрасно хватить.
В общем — да, я поэтому и написал, что «небольшие», но если сохранять страницы со всем содержимым в один файл, он может получиться нечитабельным в MSIE, может ещё где-то… поэкспериментирую, отпишусь.
>> А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
Скрипты — ещё ладно, но с iframe'ами и фреймами frameset'а ничего не получится в ИЕ.
Т.е. сохранять вполне можно, но для начала нужно эксперементально установить максимальный размер файлов для разных браузеров и при наличии файлов, превышающих данный предел, а также при наличии в документа iframe'ов и frame'ов выдавать предупреждение о возможной нечитабельности документа.
В общем — да, я поэтому и написал, что «небольшие», но если сохранять страницы со всем содержимым в один файл, он может получиться нечитабельным в MSIE, может ещё где-то… поэкспериментирую, отпишусь.
>> А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
Скрипты — ещё ладно, но с iframe'ами и фреймами frameset'а ничего не получится в ИЕ.
Т.е. сохранять вполне можно, но для начала нужно эксперементально установить максимальный размер файлов для разных браузеров и при наличии файлов, превышающих данный предел, а также при наличии в документа iframe'ов и frame'ов выдавать предупреждение о возможной нечитабельности документа.
Похоже, ограничение на длину data uri есть только в ИЕ: поэксперементировал, Opera, Firefox, Chrome нормально работают со ссылками длиной 500+, 1000+, 12000+ тыс. символов (т.е. 500 Кб, 1 Мб, 12 Мб).
Использовал готовый Jpeg на 15 кб, в котором скриптом дописывал последовательсть символов в exif данные для увеличения размера файла, затем кодировал в base64 и отдавайл в браузер HTML с картинкой в data uri.
12-мегабайтная длина ссылки data uri (со скрипом и тормозами, но открылось везде):
Opera 10.5: i41.tinypic.com/2vxiwdz.png
Chrome 4.1: i41.tinypic.com/r7kj9x.png
Firefox 3.6: i39.tinypic.com/29kxmbc.jpg
MSIE 8 ведёт себя следующим образом: если длина ссылки превышает упомянутый предел в 32768 символа, то «лишнее» просто обрезается и отображается часть данных, в данном случае, начальный кусок картинки:
i42.tinypic.com/ilaka9.png
Использовал готовый Jpeg на 15 кб, в котором скриптом дописывал последовательсть символов в exif данные для увеличения размера файла, затем кодировал в base64 и отдавайл в браузер HTML с картинкой в data uri.
12-мегабайтная длина ссылки data uri (со скрипом и тормозами, но открылось везде):
Opera 10.5: i41.tinypic.com/2vxiwdz.png
Chrome 4.1: i41.tinypic.com/r7kj9x.png
Firefox 3.6: i39.tinypic.com/29kxmbc.jpg
MSIE 8 ведёт себя следующим образом: если длина ссылки превышает упомянутый предел в 32768 символа, то «лишнее» просто обрезается и отображается часть данных, в данном случае, начальный кусок картинки:
i42.tinypic.com/ilaka9.png
P.S. Упомянутая на скриншотах «Data URI length 12 019 971 bytes» соответствует размеру файла в 8.5 Мб (9 014 960 байт — увеличение размера произошло за счёт кодирования в base64 + дополнительные символы в начале ссылки 'data:image/jpeg;base64,').
Не знал, что IE8 просто обрежет все что не помещается в его максимальный размер data uri и все равно что-то отобразит.
Я тоже не знал, поначалу попробовал мегабайтную ссылку — ни отобразило ничего, потом вспомнил, что я увеличиваю файл за счёт увеличения длины exif данных, т.е. если данные обрезаются, показывать нечего.
Поэтому попробовал что-то незначительно превышающее указанный на сайте MS предел — оказалось, не так всё и страшно :)
Поэтому попробовал что-то незначительно превышающее указанный на сайте MS предел — оказалось, не так всё и страшно :)
Для MSIE надо отдавать отдельный файл без data:url, с нормальными путями к картинкам.
почему?
Чтобы не делать таких ненатуральных плясок с бубном.
а css с data:url разве натуральные пляски? у каждого разная степень мастерства в танце. тем более так танцевать может только один на тысячу. Дело в том, что потом смогут и остальных 999 так же танцевать, если этот один сделает автоматический передвигатор ног :). Постарался объяснить на пальцах… на пальцах ног.
Эм, а в чём проблема с условными комментариями?
Не знаю, заметили все или нет, но в статье ошибочно опубликовано 3 одинаковых скрипта, для 3х разных форматов. Исправлю как только свяжусь с josser.
В архиве скрипты правильные
В архиве скрипты правильные
честно говоря так и не понял как дело обстоит с ИЕ8? под него надо отдельно генерить код картинки?
Не, на все случаи жизни генерируется 1 картинка, которая в base64 виде и вставляется в CSS.
Далее: IE6-7 не понимают datauri и скипают их, но видят css-хак '!ie' и отрабатывают mhtml.
IE8 понимает datauri до 32Kb, но не показывает их, ибо там битый CRC, а хак '!ie' он не понимает и строку с ним не отрабатывает.
Посему надо использовать css-хак который понимают все IE, либо в HEAD html добавать:
что заставит IE8 отработать как IE7 (в этом случае css-хак '!ie' сработает).
Просто я осознал что мне неизвестен универсальный, красивый и короткий css-хак для всех версий IE.
Далее: IE6-7 не понимают datauri и скипают их, но видят css-хак '!ie' и отрабатывают mhtml.
IE8 понимает datauri до 32Kb, но не показывает их, ибо там битый CRC, а хак '!ie' он не понимает и строку с ним не отрабатывает.
Посему надо использовать css-хак который понимают все IE, либо в HEAD html добавать:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7 \> что заставит IE8 отработать как IE7 (в этом случае css-хак '!ie' сработает).
Просто я осознал что мне неизвестен универсальный, красивый и короткий css-хак для всех версий IE.
>> IE8 понимает datauri до 32Kb, но не показывает их, ибо там битый CRC
Немного поэксперементировал с размерами данных, отписался чуть выше.
Немного поэксперементировал с размерами данных, отписался чуть выше.
UPD: Пример рабочего сайта перестал быть таковым.
В своем текущем проекте я вообще отказался от поддержки <IE8 и мир стал, субъективно, чуточку лучше.
Тема трансформировалась в чисто академическую.
В своем текущем проекте я вообще отказался от поддержки <IE8 и мир стал, субъективно, чуточку лучше.
Тема трансформировалась в чисто академическую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К вопросу о кроссбраузерных Data URI