Подводные грабли XSLT

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

Тут я приведу основные грабли на которые я напоролся и способы их обхода.

1. в мозилле не работает xsl:disable-output-escaping, то есть нельзя трансформировать текст в xml, что в некоторых случаях весьма удобно. в противоположность этому xslt не поддерживает сериализацию в текст, что тоже было бы удобно. в обоих случаях приходится либо на сервере нужным образом подготавливать данные, либо писать нетривиальные шаблоны для трансформации.

2. в ие нельзя указывать xsl:method="xml" ибо тогда к выходному xml-лю будет дописан xml-декларация (да, omit-xml-declaration он игнорирует ), что приводит к переводу ие в режим совместимости с древними глючными версиями. то есть метод должен быть только "html"

3. однако, если указать xsl:method="html", то в опере перестают работать формы o_0. точнее, они работают, но не посылают ни одного поля. исследования показали, поля ввода по неизвестной причине просто не привязываются к форме. причина оказалась в web forms 2.0:

Setting an element's form attribute to the empty string (or to a string consisting only of IDs that do not correctly identify form elements) just disassociates the form control from its form, leaving it unassociated with any form.

и опера, как на зло, воспринимает неустановленный атрибут "form" как установленный в значение "пустая строка". вывод - нужно задать форме идентификатор, а всем полям - атрибут form с тем же значением. уже второй раз напарываюсь на этот кривой html5.0 (слоган которого - "обратная совместимость - наше всё") и его не менее кривую реализацию в опере (-_-)

4. xsl:fallback не поддерживает ни один браузер, хотя его-то нужно было бы реализовать в первую очередь! Впрочем, внутри шаблонов можно по старинке фильтровать браузеры.

5. бойтесь вгружать xml+xslt в элемент iframe и делать "рефрэш страницы" - мозилле от этого становится очень грустно и она делает себе сэпукку. это довольно древний баг, который до сих пор так никто и не удосужился исправить. вместо ифрейма можно использовать object, правда у него есть некоторые косяки в ие...

upd: ко мне тут пришла гениально простая мысль ^_^ можно использовать method="xml", а ие переводить в режим соответствия стандартам простеньким скриптом:

window.onload= function(){
    var html= document.documentElement.outerHTML;
    if( html && ( document.compatMode == 'BackCompat' ) ) 
        document.write( '<!DOCTYPE html>\n' + html );
}

что может быть хуже чем показывать и смотреть рекламу? отлавливать в ней ошибки!

повесили на один сайт google adsense. в мозилле, опере всё пучком, а ИЕ что-то кортачится - ничего не показывает кроме ошибок: "незавершённая строковая константа" и "недопустимый символ". в качестве адреса указывает нашу страницу. номер строки и символа - циркулирует между пятком вариантов.

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

страницы у нас отдаются в utf-8, но гугол свою рекламу почему-то отдаёт в windows-1251. подозреваю он определяет язык (по региону или по http-заголовку, не суть в общем) в соответствии с ним отбирает объявления (из 6 ссылок 1-2 на русском языке) и по неизвестной причине выбирает кодировку 1251. ие в заголовках её не запрашивает, исходная страница в utf-8, видимо гугол просто для русского языка по дефолту шлёт 1251 и тем самым совершенно не учитывает поведение детища мелкософта - эта мохнатая скотина плевать хотела на http-заголовки подгружаемого яваскрипта. ие при загрузке скриптов и стилей устанавливает для них ту же кодировку, что и на странице для которой они загружаются. как следствие, ие думал, что подгружаемый гуглоскрипт с рекламными данными был в кодировке utf-8 и встретив там русские буквы, которые не входят в ASCII-7, получал совершенно невообразимые коды символов.

как обойти такое поведение ИЕ? да очень просто! есть два варианта:
1. отдавать скрипты в той же кодировке, что и исходная страница.
2. указать в тэге <script> атрибут charset содержащий код нужной кодировки.
если меня читают товарищи из гугла, то в этот их скрипт нужно добавить:

document.write('<script language="JavaScript1.1" 
charset="windows-1251" src="'+c+'"><\/script>')

естественно вместо "windows-1251" нужно подставить ту кодировку в которой собираемся грузить данные.

да, и отдельное спасибо за то, что мне пришлось копаться в этой лапше (-_-)

операция прервана высшими силами

недавно столкнулся с такой проблемой в IE: при переходе на следующую страницу он выдаёт алерт "не удалось открыть узел... операция прервана" и отказывается грузить страницу. ctrl+f5 обычно спасает положение. так и не понял почему это происходит, но связано это с тем, что скрипт пытается работать с dom в то время как его уже/ещё не существует.

ИЕ, почему ты пытаешься делать то, чего не умеешь?

Совершенно случайно сегодня выяснил, что если для xml файла указать доктайп, то ИЕ этот dtd скачает и попытается проверить соответствие xml этому dtd. Всё бы хорошо, но...
1. Некоторые dtd он не может распарсить, выдавая при этом разные ошибки синтаксиса. например - html4.1 strict
2. С другими же он на некоторое время подвисает - на моём двуядерном горе - от одной до трёх секунд.

В итоге пришёл к выводу, что доктайп лучше не указывать. xml - он и без доктайпа xml ^_^. Правда есть один минус - валидатор не хочет проверять, поэтому ему нужно явно указывать в соответствии с каким dtd нужно осуществлять проверку...