agenda 2004-03（上旬）

前回、DOM Level 2 HTMLを考慮に入れないと書きましたが、するとdocument.cookieが使用できなくなりますのでこれを撤回します。

こうなると、document.writeメソッドを忌避する理由が無くなり、DOM Level 2 StyleSheets等に拘る理由も消えます。

本来、CSSの切り替えはブラウザが行ってくれれば良いわけですが、そのようなブラウザでも幾つか不満が残ります：

• 切り替えたCSSの情報を保持してくれない
• 代替スタイルシートが予め用意されていなければならない

前者はdocument.cookieの書き換え及び参照で解決できますが、問題は後者です。実はDOM Level 2 (StyleSheets|CSS)的には、この問題を解決する方法はありません。CSSスタイルシートは、CSSStyleSheetインターフェイスを持ったオブジェクトとして扱われます（例えば実装ブラウザではdocument.styleSheets.item(0) でこのインターフェイスを持ったオブジェクトにアクセスできます）。しかしながら、このCSSStyleSheetインターフェイスを持ったオブジェクトを作成する手段、DOMImplementationCSS.createCSSStyleSheetメソッドを実装しているブラウザがありません（今のところ）。あったとしてもStyleSheetsコレクションに追加する手段がありませんから無意味です（参照：作成と追加をいっぺんにやってくれる、MSIEの document.createStyleSheet ）

まず、「叩き台」の意味を誤解しないでください。ほぼ無意味な注意書きですが一応。

今回は、addEvent関数を見てみます。

function addEvent(obj, eventType, func) {
    if (obj.addEventListener) {
        obj.addEventListener(eventType, func, false);
    } else if (obj.attachEvent) {
        /* WinIE5-6用 */
        obj.attachEvent('on' + eventType, func);
    } else {
        /* MacIE5用 */
        if (eventType == 'load') {
            obj.onload = func;
        } else if (eventType == 'change') {
            obj.onchange = func;
        }
    }
}

CSS切替スクリプト - 徒委記 より

これは主にwindow.onloadの代替に使用されるものだと思われました。疑問に思うのは、window.addEventListenerは「可能」か、言い換えるとwindowオブジェクトがEventTargetインターフェイスを持っていることを何が保障してくれているのかということです。

The EventTarget interface is implemented by all Nodes in an implementation which supports the DOM Event Model. Therefore, this interface can be obtained by using binding-specific casting methods on an instance of the Node interface. The interface allows registration and removal of EventListeners on an EventTarget and dispatch of events to that EventTarget.

Document Object Model Events より

windowオブジェクトはall Nodes に含まれるのでしょうか。DOMツリーとしてはHTMLの上に最上位ノードの#documentがあって終わりです。

同じ疑問を持っている人が誰もいないようなので不安なのですが、Mozillaが実装しているwindow.addEventListenerというのは、ひょっとして、DOM Level 2 Eventとは何の関係も無いのではないでしょうか?

        if (eventType == 'load') {
            obj.onload = func;
        } else if (eventType == 'change') {
            obj.onchange = func;
        }

obj["on"+eventType] = func;

次のxsl:variable要素がトップレベル（ルート要素xsl:stylesheetの子供）にあるとします：

<xsl:variable name="test.fragment">
	<li n="1" />
	<li n="2" />
	<li n="3" />
</xsl:variable>

$test.fragmentとして参照できるオブジェクトの型はノード集合ではありません。従って、<xsl:for-each select="$test.fragment" />等とするとエラーになります。これは結果ツリーフラグメント（Result Tree Fragment）と呼ばれるXSLTの特殊な型です。string型として評価可能かどうかのチェックが行われ、しかし評価する際にはノード集合として扱われる、と考えて差し支えありません。つまり<xsl:for-each select="$test.fragment" />は、<xsl:for-each select="'文字列'" />と同じ理由で弾かれることになるのです。

仮に私がXSLTの試験問題を作るとしたら絶対このネタを使うだろう、という程に重要かつ誤解しやすいポイントなので要チェックです（11.1 Result Tree Fragments（XSL Transformations (XSLT)））。

この「結果ツリーフラグメント」を「ノード集合」と等価に扱うにはどうするか、というのがこの記事の要点です。

document関数を利用し、スタイルシート自身を経由したロケーションパスで表現することで解決します。

<xsl:variable
  name="test.nodeset"
  select="document('')/*/xsl:variable[@name = 'test.fragment']" />

ここで、document('')は（殆どの場合）スタイルシート自身のルートノード一つを含んだノード集合です。相対URI（''）の解決は、第二引数がない場合スタイルシート自身のURIとなるからです。正確にはdocument()関数を含むスタイルシートのノードのBase URIが基底になるので、そのノードが外部実体の場合はどうなのでしょうか。面倒くさいし話題が逸れまくるので考えないことにします。

ともかくこれで変換元文書（ソース文書）に依存しない、スタイルシート編集者による任意のノード集合を変数を通じて扱うことが出来ます。

T/Oとしたいところですが、例えば汎用的なスタイルシートを公開する際、XMLの構造そのものをユーザー（クライアント）が定義、という形式が可能です。具体例は面倒なので省略。

何回繰り返し処理する、という場合にはxsl:call-templateの再帰で行うのが通例ですが、例えば先に示した変数を使用すると、三回繰り返す場合には次のように書けます：

<xsl:for-each select="$test.nodeset/*">
  （処理内容）
</xsl:for-each>

見た目がシンプルになる場合がある、というだけであまり推奨したくはありません。

結果ツリーフラグメントを入れるxsl:variable要素の方をカラッポにしておいて、プロセッサクラスにDOMノードツリーをそこに挿入するメソッドでも追加すれば、構造化されたパラメタを渡すことが出来ます。以前書いたXSLTをテンプレートとして使用するの方法より汎用的です。