Подводные грабли 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 );
}

светлое будущее, наконец, наступило!

помните, с чего началась вся эта эпопея с xml, xsl, xhtml и прочими иксами?

сначала был html, представляющий из себя кашу из данных, оформления и поведения.
потом появились такие технологии как css и javascript, которые позволяли отделить от данных оформление и поведение, но в данных всё-равно оставалось много мусора - семантически незначимых конструкций, а представлять данные требовалось так как их может воспринять браузер - ограничиваясь весьма жёсткими рамками html.

тогда появился xml - формат не накладывающий ограничений на структуру данных. в нём можно использовать свои тэги, вкладывать так как считаешь правильным и многое другое.
естественно, браузеру всё-таки надо было объяснить как эти данные следует отображать. css был недостаточно функционален для отображения произвольных данных, поэтому был разработан xsl, который весьма прохладно был воспринят создателями браузеров. тем не менее, его младшему брату xslt повезло больше: ввиду того, что он не требует переписывать весь браузерный движок, а выступает в качестве посредника, трансформирующего исходный xml в html уже понятный браузеру, его поддержка довольно быстро появилась в ИЕ, мозилле и сафари - основной троице браузерных движков. последней, сравнительно недавно, к ним подключилась и опера (девятая версия).

что мы получили в итоге? получили мы возможность на запрос клиента отдавать только данные в удобной нам форме. если браузер не знает что эти данные означают - он качает xslt и трансформирует их в xhtml. если он не знает как они должны выглядеть - качает css и показывает. если же он не знает как они должны себя вести - качает javascript. xslt, css и javascript качаются один раз и оседают в кэше. при каждом запросе передаётся только экстакт данных в формате xml.

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

чтобы не быть голословным, предлагаю реализацию на php:

function native2xml( $var, $name='root' ){
  $xml= '';
  if( is_object( $var ) || is_array( $var ) ):
      foreach( $var as $n => $v )
          $xml.= native2xml( $v, $n );
  else:
      $xml= htmlspecialchars( $var, ENT_NOQUOTES, 'UTF-8' );
  endif;
  if( is_numeric( $name ) ) $name= 'item';
  return '<'.$name.'>'.$xml.'';
}

просто передайте этой функции дерево объектов и получите на выходе xml-строку.

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

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

есть ещё два варианта "объяснения" браузеру как работать с данными:
1. javascript - трансформирование с его помощью - редкостный изврат.
2. OWL - очень мощная технология, но на данный момент никем не поддерживаемая. есть подозрение, что её ждёт та же учесть, что и XSL (-_-)

как побороть рекламу на бесплатном хостинге?

некоторые бесплатные хостинги впендюривают свою рекламу куда ни попадя. jino-net, например, вешает свой баннер справа вверху страницы. newmail - добавляет в конец страницы форму ввода (зачем??).
кроме порчи внешнего вида портится и вся вёрстка, что помимо невозможности применения html валидатора и консоли ошибок (ибо ошибок в итоге получается вагон и маленькая тележка) грозит ещё и непонятными глюками в рендеринге страницы.
борятся с этим обычно добавляя в конец страницы хитрую комбирацию тэгов и скриптов, которые деактивируют вредоносный баннер, но вёрстка получается ещё более плачевной.
как с этим бороться? да очень просто - переименуйте ваши html файлы в *.xml и если они будут являться валидным xhtml - в опере и мозилле вы увидите страницу без каких-либо признаков баннеров. с ИЕ ситуация сложнее - ему нужно объяснить, что то, что скрывается у вас под расширением xml, является на самом деле html. для этого можно применить xslt преобразование, которое можно взять, например, отсюда: http://www.w3.org/MarkUp/2004/xhtml-faq#ie.
а также из моего примера: http://dark-demon.nm.ru/web/samples/xhtml/index.xml
первый - самый простой и быстрый. второй же позволяет дополнительно трансформировать файл.
я проверил также на jino-net.ru - исправно работает. на других хостингах тоже не должно возникнуть проблем.

XHTML в массы!

Демка моего XHTML+XSLT+CSS+JS фреймворка с пояснениями: http://dark-demon.nm.ru/web/samples/xhtml/index.xml

Поскольку своего движка на PHP я ещё не написал, комменты постим здесь, на этом кривом блоге.