Pull to refresh

Comments 87

UFO just landed and posted this here
Web плавно переходит на асм
Если сделаете онлайн сервис для конвертации — цены вам не будет :)
Честно говоря, не знаком с этой технологией и из описания не понял существенных плюсов и технологии применения.
Поясните как для чайника, в чем плюс в отличии от обычных изображений и в чем заключается технология, в обработке каждой закачиваемой картинки?
Один http запрос за большим css файлом с внедренными картинками, нежели много запросов за кучей мелких картинок.
а не проще все изображения (в особенности одного размера) поместить в одну картинку-полоску и через css обращаться к какждой картинки из этой полоски (забыл как это называется)?
спрайты называется, вопрос в автоматизации сбора такой картинки и пересбора при изменениях
Автор попросил передать Вам ответ:
если все файлы забить в css sprite то невозможна тонкая оптимизация изображений, допустим по палитре
Так sprites обычно делается для мелких иконок, которые в общем-то, и 1 запрос к спрайту с оверхедом 5-10 Кб гораздо лучше 5-10 запросам по 512 байт.

Вот реальная проблема — это сложности при переверстке, это да. + для Хромого надо еще в png8 все полупрозрачные картинки дублировать.
пока не загрузится вся картинка, будет ощущение что сайт не загрузился до конца, эффект пропадет
почитайте на webo.in про это, или посты sunnybear
Контент-картинки надо грузить оттдельно (причём можно через lazy load). В CSS через DATA URI интегрировать только вёрстку. Пока она грузится, возможно, стóит затенить стреницу и вывести крутилку. IMHO.
> Один http запрос за большим css файлом с внедренными картинками, нежели много запросов за кучей мелких картинок.

А пепревешивает ли выигрыш от этого ту проблему, что объём в Base64 больше чем исходный?
Предполагаю, что если статику отдает не nginx, то выигрыш от уменьшения числа соединений есть.
Но я не эксперт, точно не знаю.

Если речь о 20-30 картинках, то можно вообще не заморачиваться я думаю. Разница заметна на нескольких сотнях (богатые интерфейсы, онлайн приложения, игры).
> т.к. приходилось 1 файл передавать два раза — раз для IE, в mhtml, и второй для всех остальных, в data uri

а почему передавать два раза? один раз для ИЕ, и один раз раз для всех остальных. если правильно подключать — совместная передача не происходит. Попробуйте duris.ru, там реализован механизм подключения только того что нужно.

а вообще статья отлично расписывает возможности объединения файлов, думаю пригодится.
кстати, а может стоит разделить css файл на две части, отдельно css без data:uri и отдельно css mix data:uri + mhtml, тогда будет возможность прогнать первую часть через css компрессор да и не надо будет писать постоянно Content-Type: text/css;

и было клево с PNG сделать без предварительного прогона через optipng.

Спасибо за исследования! очень редко такие статьи стали появляться.
А как называется этот интересный шрифт у Вас на схемках?
засада, подтверждаю в ИЕ8 не работает
Автор попросил ответить:
файлы из архива и сайт по ссылке не отрабатывали в IE8 потому что хак, который я использовал в css работает только с <IE7. Сейчас на сайте включен режим эмуляции IE7 и все нормально отрабатывает. Для более изящного решения нужен другой css хак.

img215.imageshack.us/img215/5381/201004122229181680x1050.png
это пруфскрин
для ИЕ8 надо как-то указать чтобы работал как обычные нормальные браузеры, используя data:uri
И ещё чуть-чуть:
можно и без дуриса, просто через .htaccess передавать файл с одним mhtml для ie и с datauri для всех остальных. сейчас для ie передается не gzip'нутый css, а для остальных gzip'нутый. Без optipng можно, но для этого поля в png файле должны быть выставленны в правильном порядке (в таком, в каком их понимает мой скрипт), а optipng это просто удобно. Но никто не мешает написать свой скрипт\улучшить сцществующий. Мои скрипты лишь пример реализации.
можно, хотя я думаю что оптимальнее эту логику на клиенте расположить. Скрипт однозначно стоит улучшить, при возможности портирую на Java.
UFO just landed and posted this here
Есть проблема в IE7 под Vista.
проблема была, но уже решена, смотрите ссылку в комментарии ниже
Хм… Технология, возможно, хороша, но намного ли это будет быстрей CSS спрайтов со внешней картинкой? Да, со спрайтами на один HTTP запрос больше, но стоит ли этот один запрос такого усложнения цикла разработки сервиса?

Ведь на странице у вас в любом случае будут картинки помимо закодированных — фотографии, иллюстрации к статьям или портфолио и т.п. Да и на любом мало-мальски серьезном проекте всегда есть что усовершенствовать помимо data:URI.

В общем, вопрос в чем: адекватны ли затрачиваемые усилия достигаемому результату?
вопрос в полной автоматизации создания data:uri css sprites, что не реализуемо на 100% при обычных спрайтах.
Вопрос адекватности — не только в автоматизации.

Подобная оснастка усложняет цикл разработки, заставляет проводить дополнительное тестирование (удостовериться что со спрайтами все не поехало), усложняет отладку (т.к. финальные прогоны надо делать с уже «заспрайтованными» файлами, а там будет не очень-то человекопонятное CSS).

На больших проектах это достаточно сильно может увеличить трудоемкость, даже если будет автоматизировано.

Получится ли сопоставимый этому геморрою результат?
все это (как и спрайты) полностью автоматизируется. Не зря же WEBO Site SpeedUp уже год успешно работает :)
А разве можно автоматизировать создание спрайтов? Там же все может быть очень сложно сделано.
может быть, а может и не быть.
Мы год назад эту задачу в 95% случаев решили. И только через полгода Steve Souders выкатил свой SpriteMe, который не все возможные случаи обсчитывает.
Ну не знаю, что-то сомневаюсь я, бывают же когда ширина/высота в стилях прописана не в пикселах (или вообще не прописана), background-position не в пикселях, бывает определения раскиданы по разным селекторам, бывает для ИЕ отдельные правила.

А банальные определения типа height: 20px, width: 20px, backgound-position: 50% — это да, наверно автоматизируется.
95% случаев автоматизируется. Даже с относительным background-position, даже без задания размеров, даже когда определения по разным селекторам раскиданы.
зато с data:uri автоматизируются 100% :P
получится, нужно просто иметь нормальное автоматизировано средство от геморной боли
в нормальной проекте все равно используется какой-то инструмент оптимизации. вызовом одного скрипта собирается весь оптимизированный билд.
В теории — да. Но на практике, как я понимаю, пока такого средства не только нет, но и сами даже выкладки существуют только в теории и никем серьезно на нормальном проекте не тестированы?
интересно, каким образом duris к живому сайту прикручивался…
с помощью offline версии, кстати сейчас режим тестирования проводим, если есть достойный проект — могу сделать билд под него

для этого необходимо написать письмо на адрес duris.ru[гав]gmail.com (ну или мне в личку) с пометкой в теме «duris offline». В письме укажите следующие данные:
— язык программирования
— кратко опишите прицип работы и структуру проекта
— ссылка на online сайт проекта

обычные домашние страницы не рассматриваются, на данный момент отрабатываем под проекты средней и выше средней сложностей.
спасибо!
будет сделано в скором времени!
намного. Просто поверьте :)
Ответ автора через моё посредничество:
сия технология не всеобъемлюща и не идеальна. через нее стоит пропускать лишь те изображения, которые встречаются на каждой странице(или просто часто). После написания скриптов процесс внедрения занимает ОЧЕНЬ мало времени.
С swf случайно не эксперементировали в MHTML?

Довелось поковыряться с внедрением swf для копирования текста со страницы в буфер обмена — flash-плагин не поддерживает data uri (на сайте Adobe было упоминание, что пока и не планируется добавление поддержки), а браузеры самостоятельно не преобразовуют данные перед передачей плагину, в итоге пришлось отказаться от этой затеи.
*экспериментировали

К ночи пальцы путаются…
Автор попросил передать, что:
ой
…что:
нет, с swf не экспериментировал
Кстати, если кто-то хотел бы поделиться с автором статьи инвайтом — он был бы не против его получить. Пишите мне в личку, дам адрес электронной почты.
Ну или пишите по приведённому в конце статьи jabber-адресу: banderlog@jabber.com.ua.
спасибо тов. Artqookie, инвайт получен X)
отдельная благодарность тов. dtf за согласие побыть некоторое время посредником :)
Мне кажется лучше не парится и отдавать 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)}
* html {}
*+html {}
^^^ смотрится элегантнее и меньше байтов :)
>> меньше байтов :)

Тогда уж в первом случае можно без пробела после астериска:
<tt>*html{}</tt>


:)
*html{}

Irony и всё остальное парсер режет, а tt оставляет и даже со скобками, странно.
Полностью поддерживаю. Я тоже не заморачиваюсь с IE6 и 7 и отдаю им спрайт из изображений, а нормальным браузерам css-файл с dataURL изображениями.
Спасибо. Не знал раньше вообще что есть такая Data URI.

Помимо указанного применения с интеграцией графики в CSS сразу вырисовываются такие применения:

Написать сохранялку страниц, которая будет брать любую открытую в браузере страницу и давать на выходе один стандартный html-файл, внедряя внутрь него и CSS и JS и теперь ещё графику. Раньше такое уже было в MHT, но теперь есть возможность делать стандартный HTML.

Внедрять картинки в почтовые и др. сообщения не ввиде ссылок и не ввиде приложений, а прямо так. Кстати интересно, у кого карма положительная и теги можно использовать, попробуйте-ка в теге IMG в комменте так картинку вставить?
Не сработало. Парсер порубал содержимое атрибута src и вообще выкинул атрибуты width и height.
>> Раньше такое уже было в 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.»
Т.е. попросту — так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.
Ну да, и еёщ одно:

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&param2=value2','_blank','height=500,width=200');

работать, к сожалению, не будет.
> максимальный размер — 32,768 символа

В общем случае должно прекрасно хватить.

> так можно внедрять только картинки, а скрипты и содержимое фреймов — не судьба.

А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?
> В общем случае должно прекрасно хватить.

В общем случае — да (я потому и написал «небольших»), но если действительно сделать сохранение страниц в один файл, то могут быть проблемы с чтением сохранённого файла, если, к примеру, на странице присутсвуют большие картинки (проблемы скорее всего только в MSIE — проверю, отпишусь, самому интересно стало).

> А зачем скрипты так внедрять когда можно внутри тега script открытым текстом?

Не обязательно скрипты: содержимое iframe'ов, содержимое фреймов во frameset'е.
>> В общем случае должно прекрасно хватить.

В общем — да, я поэтому и написал, что «небольшие», но если сохранять страницы со всем содержимым в один файл, он может получиться нечитабельным в 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
P.S. Упомянутая на скриншотах «Data URI length 12 019 971 bytes» соответствует размеру файла в 8.5 Мб (9 014 960 байт — увеличение размера произошло за счёт кодирования в base64 + дополнительные символы в начале ссылки 'data:image/jpeg;base64,').
Не знал, что IE8 просто обрежет все что не помещается в его максимальный размер data uri и все равно что-то отобразит.
Я тоже не знал, поначалу попробовал мегабайтную ссылку — ни отобразило ничего, потом вспомнил, что я увеличиваю файл за счёт увеличения длины exif данных, т.е. если данные обрезаются, показывать нечего.
Поэтому попробовал что-то незначительно превышающее указанный на сайте MS предел — оказалось, не так всё и страшно :)
Мегабайтную ССЫЛКУ? Фигассе. Не дай бог такие в закладки добавлять… :)
Она же ссылка только формально, на деле — файл помещённый в ссылку, т.е. не указатель на ресурс, а по сути сам ресурс. :)
Для MSIE надо отдавать отдельный файл без data:url, с нормальными путями к картинкам.
Чтобы не делать таких ненатуральных плясок с бубном.
а css с data:url разве натуральные пляски? у каждого разная степень мастерства в танце. тем более так танцевать может только один на тысячу. Дело в том, что потом смогут и остальных 999 так же танцевать, если этот один сделает автоматический передвигатор ног :). Постарался объяснить на пальцах… на пальцах ног.
спасибо Х) Только я никак не могу взять в толк, о каком дальнейшем автоматическом передвигаторе ног идет речь. На данный момент все максимально просто и удобно (по себе равняю, понятное дело) — натравил нужный скрипт на нужный файл, и вставил строчку в CSS.
Эм, а в чём проблема с условными комментариями?
Не знаю, заметили все или нет, но в статье ошибочно опубликовано 3 одинаковых скрипта, для 3х разных форматов. Исправлю как только свяжусь с josser.
В архиве скрипты правильные
честно говоря так и не понял как дело обстоит с ИЕ8? под него надо отдельно генерить код картинки?
Не, на все случаи жизни генерируется 1 картинка, которая в base64 виде и вставляется в CSS.
Далее: 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 и мир стал, субъективно, чуточку лучше.
Тема трансформировалась в чисто академическую.
Only those users with full accounts are able to leave comments. Log in, please.