Работа в Internet Explorer

Существует три способа обойти отсутствие в IE поддержки data:URI. Используя распознавание браузеров (например, с помощью условных комментариев, ведь речь идет только про IE), можно просто отображать внешнее изображение для IE и встроенные изображения для остальных браузеров. Или вы можете применить JavaScript для эмуляции этой поддержки в IE, но эта техника потребует довольно значительного объема JavaScript‑кода. О третьем способе пойдет речь в разделе, описывающем mhtml‑технику.

Вышеприведенный PHP‑код позволяет легко вставить base64‑аналог изображения (можно расширить этот пример, чтобы, например, распознавать заголовки, отправляемые браузером серверу, и только для IE выводить URL для изображения, для остальных же кодировать его в base64):

ul {

list‑style: none;

}

ul li {

margin: 0 0 1px;

background: url(data:image/gif;base64,<?php

echo base64_encode(file_get_contents("../images/flag.png"))

?>) top left no‑repeat;

height: 14px;

text‑indent: 10px;

}

Когда сервер начнет анализировать CSS‑файл, он автоматически перекодирует бинарный файл изображения в base64 и отправит эти данные внутри CSS‑файла. Следующим шагом будет добавление распознавания браузеров для отправки изображения только IE и встроенных изображений всем остальным. Это можно сделать либо внутри CSS‑файла с PHP‑кодом, либо с помощью условных комментариев, например:

<!‑‑[if gte IE 5]>

<style type="text/css" src="ie.css">

<![endif]‑‑>

<!‑‑[if !(IE)]>

<style type="text/css" src="main.css">

<![endif]‑‑>

В файле ie.css должно быть нормальное обращение к картинке, например:

ul li {

margin: 0 0 1px;

background: url(/images/flag.png) 0 0 no‑repeat;

}

...

Преимущества и недостатки data:URI

Вместе с техникой CSS Sprites (или как ее альтернатива) data:URI может существенно уменьшить число HTTP‑запросов. Краткий список плюсов данного метода:

Экономят HTTP‑запросы, предотвращают издержки, связанные с большим числом объектов.

Экономят число параллельных потоков: у браузеров есть ограничение (по спецификации HTTP/1.1, однако Firefox, Opera и Safari несколько вольно его трактуют, в частности, позволяя настраивать этот параметр или значительно его увеличивая; о настройках браузеров можно прочитать в восьмой главе) на число одновременных соединений (подробнее об этом рассказывается в пятой главе) с одним хостом.

Упрощают HTTPS‑запросы и улучшают производительность при таком типе соединения.

Однако встроенные изображения (только data:URI) не поддерживаются в Internet Explorer 5‑7. Текстовое base64‑представление данных также занимает больше, чем бинарное изображение. В наших тестах base64‑данные были на 39‑45% больше бинарного аналога, но gzip‑сжатие позволяет уменьшить разницу до 5‑10%. Предварительная оптимизация изображений перед base64‑кодированием позволяет уменьшить их размер пропорционально (о сжатии изображений было рассказано во второй главе).

Также существует ряд ограничений на размер встроенных изображений. От браузеров требуется поддерживать только URL длиной до 1024 байтов, в соответствии с вышеупомянутой спецификацией RFC. Однако браузеры более либеральны к пользователям в том, что они принимают. Например, Opera и Firefox последних версий поддерживают data:URI примерно до 50 Кб (для IE8 этот предел составляет 32 Кб). Но все же эта техника подходит больше для небольших по размеру изображений. Краткий список минусов:

Не поддерживается IE до версии 7 включительно.

Требуются дополнительные действия для обновления внедренного содержания (перекодировать, еще раз вставить).

Ограничена длина. Не подходит для вставки больших изображений.

Изображения, представленные в base64‑кодировке, примерно на 33% больше размера их бинарного аналога (на 10% – при использовании сжатия).

Встроенные картинки (не в CSS) не получится закэшировать по определению. Они будут кэшироваться только с HTML‑кодом.