ie

В блоге Microsoft, посвящённом их браузеру появилась статья об Internet Explorer 9. То, что есть сейчас уже очень неплохо — IE9 по скорости (если верить данным Microsoft) лишь чуть-чуть отстаёт от FF 3.6 и всего в два раза медленнее Chrome 4 (учитывая насколько он шустрый, это совсем неплохо).

Internet Explorer 9.0 проходит тест селекторов CSS3 с результатом 574 из 578 (IE8 — 330/578), тест ACID3 — 32% (IE8 — 20%), поддерживает border-radius (несмотря на более ранние заявления Microsoft, что CSS3 ещё пока слишком сырой, чтобы что-то из него реализовывать, кроме селекторов) и это только начало — ведь это даже ещё не альфа-версия!

Не могу поверить, что этот движок и есть «Газель» о которой говорили ранее, ведь «Газель» имела большие проблемы с производительностью, да и в статье из блога о безопасности и изоляции вкладок (основные фишки «Газели») ни слова.

P.S. Кстати, если покопаться, то можно найти как выглядит user-agent нового браузера: «Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/4.0)», IP, откуда заходили этим браузером, принадлежит городу Редмонд (в нём работает около 30 тысяч сотрудников Microsoft).

Движок, как видим, всё ещё называется «Trident», хотя номер смущает — 4.0, как мы знаем, версия, которая входит в IE8.

Вадим Макишвили описал несколько примеров применения rgba в Internet Explorer. Примеры очень и очень полезны, и я скопирую их (без картинок, за ними идите в исходный пост) к себе:

Сегодня, благодаря этому новому знанию, я понял как решить две труднорешаемые задачи. Издавна, чтобы сделать фон блока полупрозрачным, мы вынуждены были использовать или png-24 картинку в фоне или opacity-свойство.

Но в случае с png-24, для ИЕ6 нужно писать AlphaImageLoader фильтр, который катастрофически замедляет рендеринг страницы. А в случае с opacity приходилось придумывать трюки, чтобы дети блока не бледнели от родительского opacity.

А теперь проблему opacity можно забыть, как страшный сон: .block { background: #rgba } * html .block { filter:progid:DXImageTransform.Microsoft.gradient (startColorstr=#99000000, endColorstr=#99000000); }

В начальной и конечной позиции один и тот же RGB (000000) и добавляю перед ним одно и то же значение Alpha (99) Значение Alpha указывается в 16-тиричной системе, где 00 — полностью прозрачный, а ff — непрозрачный пиксел

Я протестировал скорость рендеринга страницы, на которой выливается 300 элементов с gradient-фильтром — он не замедляет рендеринг и это сильно радует.

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

Иногда использовать png-24 всё-таки необходимо, как например в случае, когда нужно обрезать длинную неразрывную строку, уводя ее градиентом в непрозрачность.

В этом случае можно использовать второй способ. .block { background: url(image.png) } * html .block { filter:progid:DXImageTransform.Microsoft.gradient (startColorstr=#00ffffff, endColorstr=#ffffffff, GradientType=1); }

GradientType принимает значение 1, если градиент рисуется слева-направо; и 0, если градиент сверху-вниз.

MSIE хороший браузер.

Век живи, век учись. Оказывается, в Internet Explorer есть возможность, через фильтры, указывать rgba-цвет:

.element{
    /*color = black, opacity = 0.6 */
    filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#99000000,endColorstr=#99000000); /*AARRGGBB*/
    zoom: 1
}

Большая часть фильтров понимает цвет в формате argb (первая компонента — прозрачность).

На сайте JavaScript.ru появилась статья о новых событиях в JavaScript — offline и online (реализованы в Firefox 3.5 и Internet Explorer 8.0). Цитирую выводы:

Эти события никак не связаны с подключением к сети интернет и к сайту.

Они триггерятся при переходе по клику пользователя в автономный режим и обратно.

Они также триггерятся, когда отключаются все сетевые адаптеры, или подключается хотя бы один. При этом не важно, ведет ли он в реальный интернет.

Firefox глючит, в отличие от IE

Что-то Internet Explorer меня нехорошо удивляет в последнее время. Кто-нибудь, не запуская, может сказать что получится, если выполнить в IE следующий JavaScript:

alert('a###a'.split(/#/))
alert('a###a'.split('#'))

Самое главное, мне непонятно — зачем это так сделано?

Ребята из Google выпустили плагин Google Chrome Frame для Internet Explorer (поддерживаются IE6+), который позволяет переключать движок этого браузера со стандартного на WebKit. Если плагин установлен, то следующая конструкция в HTML-коде сайта переключит его отображение в режим WebKit:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Google обо всём побеспокоился, можно даже показать пользователю окно с просьбой установить Google Chrome Frame, если он ещё не установлен.

P.S. Говорил же Стив Балмер, что в Internet Explorer возможно будет WebKit! Никак пророчествовал? :)

P.P.S. Строка user-agent браузера меняется, даже если Chrome не включен: появляется слово «chromeframe».

P.P.P.S. Google Chrome Frame добавляет специальную схему «cf», например, этот сайт можно открыть плагином, если написать следующий адрес: «cf://bolknote.ru».

Ребята из Microsoft пообещали реализовать теги VIDEO и AUDIO в своём браузере. Интересно, что Microsoft просит W3C задуматься о расширении синтаксиса тегов, чтобы, например, можно было предоставить пользователю возможность просматривать (прослушивать) контент не только в разных кодеках, но и с разным качеством и/или на разных языках (!).

Моё исследование (проведённое для книги, которую мы пишем) по проблемам реализации сжатия в браузерах принесло счастье пользователям nginx:

0.8.11 Изменение: теперь директива «gzip_disable msie6» не запрещает сжатие для MSIE 6.0 SV1.

Списался с Игорем Сысоевым и с версии 0.8.11 nginx не отключает gzip-сжатие для MSIE 6.0, у которого в строке user-agent присутствует SV1. SV1 (Security Version 1) означает, что установлен Service Pack 2 для IE 6, в котором проблем с gzip нет.

В принципе, если Apple за уши притягивает результаты тестирования своего браузера и искажает факты, то почему бы Microsoft не заняться тем же? Но я всё равно шокирован:

Myth #4: Internet Explorer doesn’t play well with Web standards.

The Real Deal: Internet Explorer 8 passes more of the World Wide Web Consortium’s test cases than any other browser

Такие дела. Сравнивается с Mozilla Firefox и Google Chrome (Opera традиционно игнорируется в буржуинском сегменте, Safari нет по непонятным мне причинам).

Для интереса написал на PHP небольшой скрипт для анализа сколько соединений открывают браузеры и в каком порядке они грузят данные. Создал HTML-файл, внутри 30 включений: по 10 на CSS, GIF и JavaScript. Favicon включён и как «icon» и как «shortcut icon».

Вот что получилось (считаются одновременные соединения):

• Opera 10 alpha (build 1355) — 4 соединения к серверу, порядок загрузки: js, ico, css, gif; особенности: 0.css почему-то загружен два раза.
  — Internet Explorer 8 — 6 соединений к серверу, порядок загрузки: js, css, gif, ico
  — Internet Explorer 5.5 и 6 — 2 соединения к серверу, порядок загрузки: js, css, gif
  — Google Chrome 1.0.154.53 — 6 соединений к серверу, порядок загрузки: js, css, gif, ico
  — FireFox 3.0.7 — 6 соединений, порядок загрузки: js, ico, css и gif вперемешку; особенности: почему-то ico загружен два раза, gif и css грузились вперемешку
  — Safari 4 beta (528.16) — 4 соединения, порядок загрузки: js и css вперемешку, gif; особенности: js и css грузились вперемешку
  — Safari 3 (526.27.1) под Maкинтош — 3 соединения, порядок: js и css вперемешку, gif; особенности: js и css грузились вперемешку
  — FireFox 2.0.0.20 под Макинтош — 2 соединения, порядок: js, ico, css, gif; особенности: ico загружен три раза

Прелюдия

Некоторое время назад, я нашёл способ, использования data URI в Internet Explorer. Data URI — специальный вид URL, который включает в себя код самого объекта. Например, таким образом можно внедрять изображения прямо в код HTML-страницы.

Выглядит такой HTML вот так:

<img src="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP…и так далее" />

Где «data» — это протокол URI, image/gif — тип объекта (картинка GIF), base64 — тип кодирования, после запятой идёт сам код картинки.

Такой вид URI понимают сейчас все современные браузеры, включая Internet Explorer 8 (правда, со многими ограничениями). Плохо то, что Internet Explorer 7 и ниже этого не поддерживает, а доля этих версий настолько велика (около 50% на данный момент по данным LiveInternet), что до недавнего времени data URI использовалась крайне редко.

Я, увлёкшись исследованием малодокументированного протокола mhtml (MIME HTML), поддерживаемого в браузерах Microsoft с пятой версии, в одном из экспериментов разобрался как внедрить объект в тело HTML-документа и, что важнее, придумал как совместить оба способа (data URI и MHTML) в одном документе.

Вообще mhtml был придумал для адресации внутри так называемых «веб-архивах» — формат, очень похожий на формат писем электронной почты и предназначенный для сохранения веб-страниц вместе с картинками, стилями, JavaScript и прочим в одном файле. Сейчас он, так или иначе, поддерживается большинством браузеров.

Типичный mhtml-адрес выглядит следующим образом:

mhtml:http://example.net/index.html!fhhryregdy4gere

Где после «mhtml» идёт обычный веб-адрес, а после восклицательного знака — идентификатор объекта внутри веб-архива. Как я уже сказал, веб-архив очень похож на почтовое сообщение, где один из методов кодирования объектов — base64, тот же самый, который применяется и в dataURI.

В итоге, когда мне пришла эта идея, я совместил оба способа так, чтобы Internet Explorer видел файл как веб-архив с закодированным base64 объектом, а остальные браузеры видели этот закодированный объект как часть dataURI.

Специфика HTML допускает переносы, в том числе и внутри data URI, поэтому мне удалось задуманное относительно быстро. В CSS всё сложнее, а тема использования data URI в CSS, как оказалось, актуальнее, чем для HTML. Например, в книге Николая Мациевского «Разгони свой сайт» сделана попытка расширения моего способа на CSS, к сожалению, менее удачная, чем хотелось бы: требуется включение закодированного объекта два раза.

Фуга

Итак, мне захотелось посмотреть, не получится ли расширить мой способ на CSS, не прибегая к включению закодированного файла два раза. Причём, сфера тут уже, подключаемый к CSS объект это, в 99,99% — картинка.

После немногочисленных экспериментов, оказалось, что оторвать закодированный объект от начала data URI не представляется возможным, что мешает использованить mhtml — там заголовок и кодированный объект должны отделяться пустой строкой.

Тем не менее, других способов побороть IE я не видел и потому продолжал эксперименты. Несколько слов о том, что такое base64. Base64, по сути, анахронизм, доставшийся нам от электронной почты на заре её зарождения. Письма тогда ходили исключительно в латинице и все почтовые системы полагали, что никаких других символов в письмах не бывает.

Таким образом, когда встала задача передавать в письмах что-то кроме англоязычных текстов (например, файлы или тексты на других языках), было придумано несколько способов кодирования таких объектов. Один из них — base64 (для математиков — это позиционная система счисления с основанием 64). 64 — это количество знаков, которая использует это кодирование. Это символы A-Z, a-z, 0-9 и плюс со слешем.

Хорошие новости, заключаются в том, что браузеры игнорируют в кодированной строке символы, которые не входят в упомянутые 64. Можно было ожидать, что браузеры вообще откажутся разбирать такую строку.

Итак, строка data URI начинается с чего-то вроде «data:image/gif;base64,» и в CSS не терпит переносов, а MHTML требует, чтобы кодированная строка начиналась с начала строки.

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

Оставим в покое XBM, BMP, ART, WMF/EMF, JPEG200 и прочую экзотику, поддерживаемую браузерами, и остановимся на триплете JPEG, GIF, PNG. Честно сказать с форматом GIF я знаком плохо, а JPEG и PNG исследовал несколько лет назад довольно подробно.

JPEG и PNG состоят из секций. В общих чертах, сначала идёт заголовок файла, потом сами секции, в формате (с некоторыми вариациями) «имя секции», «длина секции», «конец секции». И у JPEG, и у PNG есть секции для произвольного содержимого. У JPEG это COM и APPn, у PNG — iTXt, tEXt и zTXt. Кстати, и у GIF тоже есть похожее место — Application Extension.

Отсюда идея: Internet Explorer, декодировав файл с начала строки, получает заголовок с секцией из содержимого, куда помещается заголовок для остальных браузеров и мусор, оставшийся от декодирования начала data URI, остальные браузеры должны пропустить заголовок для IE и начать декодирование с data URI.

Получаем, на примере JPEG:

FF D8 — заголовок JPEG для IE FF E0 xx xx — секция APP0, куда прячется всё до данных изображения, «;background-color:url(data:image/jpeg;base64,» — это видят остальные браузеры FF D8 — начало JPEG для остальных браузеров «данные изображения» — это место видят уже все браузеры

Все бинарные данные выравниваются и кодируются (строка начала CSS-стиля для остальных браузеров не кодируется и IE декодирует её как мусор внутри APP0).

В моём примере такой CSS выглядит вот так:

/9j/4AAs;background-image:url(data:image/jpeg;base64;BOLKNOTE.RU,/9j/4AAC…

Легко увидеть, как видит этот стиль браузер: «/9j/4AAs» кажется ему ошибочным атрибутом (его, кстати, можно взять в комментарий), а «;» — разделителем атрибутов. И хорошо просматривается («/9j/AA») двойной старт заголовка JPEG-файла. IE начнёт декодирование с первого заголовка, другие браузеры — со второго.

Остальное должно быть понятно из примера («!ie» — CSS hack, делающий стиль видимым только для IE), как это выглядит в браузере, можно увидеть в разделе «Храню» у меня на сайте.

Вышел релиз Internet Explorer 8 со вкусом «Яндекса».

Microsoft опубликовала смешной документ, в которым утвержается, что IE8 самый быстрый браузер in da world. Методика тестирования — время загрузки 25 сайтов (а почему нет «Оперы», кстати?):

For the Internet Explorer 8 performance video we published, we chose the Top 25 websites in the world as measured by comScore to reflect the sites users are most likely to visit on the web. The following table shows results from the benchmark testing process for those 25 websites tested on the following browsers: Google Chrome, Mozilla Firefox, and Internet Explorer 8.

Ха. Ха. Ну-ну.

Но то, что в этом режиме простое обращение к document.body.filters волшебным образом прекращает дрожание (как background-position:fixed в рецепте от студии Лебедева) — похоже, открытие. Больше того, по моим наскоро проведенным опытам, аналогичный эффект дает и такая бессмысленная (как и вышеприведенный скрипт!) запись в CSS:

body { _filter: true; }

Способ «background-position: fixed» знают многие, а вот такие трюки с filter — что-то новенькое.

Как сегодня пишет AppleInsider, глава компании Microsoft Стив Балмер не отрицает возможности использования движка для рендеринга веб-страниц WebKit в одной из следующих версий браузера Internet Explorer.

Цитата из статьи на Macspoon. OMFG!

На сайте MSDN нашёл полезную страницу, где очень понятно, по разделам описывается что из CSS умеют различные версии Internet Explorer (5.0, 5.5, 6.0, 7.0, 8.0beta1, 8.0beta2, 8.0).

Нашёл CSS-хак для Internet Explorer 7.0 и 8.0:

-, body { background: gray; }

Основан на баге парсера браузера, который был введён для того, чтобы обрабатывать стили, начинающиеся с «-» (в IE7 появился первый стиль с префиксом «-ms-»).

Google добавил отличнейшую штуку в Google Gears: определение географических координат пользователя по различным сетям (wi-fi, сотовые сети, GPS, что доступно). Например, на ноуте будет использованы идентификаторы wi-fi сетей, которые есть вокруг.

Фокус в том, что эту информацию можно запросить прямо с веб-страницы из JavaScript. При первом обращении бразер показывает сообщение, что сайт запрашивает информацию о географическом положении пользователя и предлагается на выбор довериться этому сайту или отказать ему в получении этой информации.

Способ использования до смешного прост: на страницу подключается gears_ini.js, а далее координаты доступны как свойства latitude и longitude объекта, который попадает в callback-функцию обновления координат.

Документация небольшая и полна понятных примеров.

Врёт API пока сильно (я на Таганке, меня показало на Охотном ряду) и под FF (хм…) у меня не заработало, пробовал под 3.0.3 и 3.1beta1.

Есть у меня такой любимый синтетический тест браузеров — запускать на своём древнем интерпретаторе языка Brainfuck вычисление числа Пи (программа есть на том же сайте).

Для интереса запустил его на браузерах, которые нашлись у меня на машине. Итог:

FireFox 3.1b1pre — 693 + JIT (410) = 1103 Opera 9.60 — 1141 + JIT (828) = 1969 Safari 3.1 — 1719 + JIT (547) = 2266 IE8 beta 2  — 2422 + JIT (843) = 3265 Chrome 0.2.149.30 — 7731 + JIT (950) = 8681

«1719 + JIT (547) = 2266» означает, что браузер проработал чуть больше двух секунд, из них полсекунды заняла внутренняя оптимизация кода на Brainfuck, которую делает мой интерпретатор, а 1.7 секунды выполнялся код на Brainfuck.

Как видно у Chrome не всё хорошо с JavaScript.

Как-то все забыли про ACID3. Проверил им Internet Explorer 8 beta 2 и Chrome (специально для этого скачал!). Итак, по сравнению с ближайшими конкурентами:

Opera 9.60beta1 — 85% FireFox 3.1 beta1 — 85% Chrome 0.2 beta — 79% WebKit r36309 — падает на 26% Internet Explorer 8 beta 2 — 21%