先日、クライアント側のxslt変換の分野でブラウザー開発者が達成した成功を見つけるために着手しました。 サーバーで変換を実行する方法は興味深いものではないため、リソースが消費され、チャネルが消費されます（これは、弱いチャネルと強力なコンピューターのユーザーにとって特に重要です）。 とにかく、私の意見では、クライアント側の変換は単純に正しいです。 ドキュメントを表示するタスクは、ブラウザのタスクです。 さて、彼にこれをさせてください。
xsltprocプログラムの結果は、変換の正確さの標準として採用されました。
ここに私が得たものがあります：
何らかの理由で、xsl：output method =“ xml”メソッドを指定する場合、 OperaもFirefoxも頑固に変換を実行したくありません。 より正確には、彼らは何らかの形でそれを実行しますが、正しく表示しません-フォーマットせずに画面上でテストが失敗するだけです。
xsl：output method =“ html”が指定されている場合（デフォルト）、変換は実行されますが、xsltprocプログラムの出力は純粋にhtml-<br>、<hr>、nowrapになります。 OperaとFirefoxエンジンの変換の結果を確認する方法がわかりません。 （多分すべてうまくいっているかもしれません...）両方のブラウザですべてが正しく表示されているので、心強いです。
JavaScriptおよびxslt。
ここでは、すべてがやや興味深いことが判明しました。 既知のすべてのバナーネットワークに一定数のバナーがあり、サイトにはいくつかのボタンとカウンターがあります。 バナー表示コードは簡単なdocument.writeです（ '<a href= first some.site "> <img src = " path / to / banner "> </a>'）; （はい、確かに<img>タグには/>がありません-人々はお金を稼ぎ、標準を守る時間はありません。:)）。 このナンセンスをすべて個別の.jsファイルに入れ、必要に応じて<script src = "banner1.js"> </ script>を挿入しました。 xsltprocは、このレイアウトを有効なxhtml / strictにオーバークロックしました。 Operaはそのようなコードを単に無視しました。 Firefoxは最初のバナーを処理しようとすると最初につまずき、その後単にクラッシュしました。document.writeはDOMモデル全体を単純に上書きするため、最初のバナーのみが画面に表示されました。 DOMモデルを書き直そうとすると、firefoxは塔を撃ったようです。
その結果、DOMモデルを通じてバナー表示コードを通常に書き直し、すべてが正常に表示されるようになりました。
PS
これらの実験を設定してしばらくして、xsl：output method = "xhtml"が追加されたXSL 2.0があることを知りました。 （これまでのところ、Operaだけがこの出力方法を理解しています。結果はmethod =“ html”と変わりません。単純な例でテストしただけかもしれません。Firefoxはまったく理解していません。）どのような形。 javaには実装があります。 しかし、gnomのovsky libxml / libxslt （PHPインタープリターが使用する）はまだそれ自身を引き上げていません。