`DocumentPosition`

[11] 驚くべきことに DOM3 仕様上は関係がほのめかされているだけで明示されていないのですが、 compareDocumentPosition は定義群 DocumentPosition に属する定数によるビットマスク値を返します。

[12] 界面 Node の定義群 DocumentPosition には、データ型が unsigned short である以下の定数があります >>13。

DOCUMENT_POSITION_DISCONNECTED (0x01): 両節点は連結ではありません。 (連結していない節点の順序は常に実装規定です。)
DOCUMENT_POSITION_PRECEDING (0x02): 与えられた節点は参照節点に先行する節点です。
DOCUMENT_POSITION_FOLLOWING (0x04): 与えられた節点は参照節点に後続する節点です。
DOCUMENT_POSITION_CONTAINS (0x08): 与えられた節点は、参照節点を含んでいます。 (含む節点は常に先行する節点でもあります。)
DOCUMENT_POSITION_CONTAINED_BY (0x10): 与えられた節点は、参照節点に含まれています。 (含まれる節点は常に後続する節点でもあります。)
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC (0x20): どちらが先行でどちらが後続かは実装規定です。

処理モデル

[8] このメソッドがよばれた節点を参照節点reference nodeとするとき、参照節点と第1引数に与えられた節点についての文書中での位置を文書順に基づき調べてビットマスクとして返します >>2。

ビットマスクの決定

[18] このメソッドは2節点間の文書中の相対位置を表すビットマスクを返します。この値は次のようにして決定されます。 >>13

[19] 2節点が同じ節点なら、フラグは何も設定せずに返します。
[20] そうでなければ、共通の包含子 (両節点を含むcontains節点) を探します。
- [21] 節点は、その子節点を直接含みます。
- [22] 節点は、附属しているattached他の節点 (要素に対する属性、文書型に対する実体や記法など) を直接含みます。
- [23] 含まれている節点に含まれている節点もまた含まれる節点ですが、間に挟まる節点が増えるほど「直接」度は減少していきます。
1. [24] 共通の包含子節点がなければ、
  - [25] 両節点の根包含子 (包含子がない節点つまり最も外側の節点) 同士の順序によって順序が決定します。
  - [26] 結果は、連結しておらず、実装規定です。
  - [27] この結果は、根包含子がメモリー上に残っており、他の包含子節点に挿入されない限り、安定です。
2. [28] 一方が他方の節点を含んでいるなら、包含子が含まれている節点に先行し、含まれている節点が包含子の後続となっています。
3. [29] >>24、>>28 のいずれでもない場合には、両方の節点のどちらの包含子でもあって、最も「直接」的である節点が存在するはずです。この場合、そのような節点が直接含む節点に、比較対象の節点または比較対象の節点を含んでいる節点が丁度1つずつ、合計2つ存在するので、その順序によって比較対象の節点の順序が決まります。
  1. [30] 両者がともに子供節点なら、自然な DOM 上の順序を返します。
  2. [31] どちらかが子供で他方がそうでないなら、子供である方が子供で無い方に後続するものとします。例えば子要素は属性に後続する (属性が先行する) とします。
  3. [32] どちらも子供でなく、 nodeType が異なるなら、大きい順とします。
  4. [33] どちらも子供でなく、 nodeType も同じなら、順序は実装依存です。
    - [34] この順序は同じ nodeType の節点が直接の包含子に挿入されたり削除されたりしない限り安定です。

[35] >>33 が「実装規定」ではなく「実装依存」なのは、typo なのか意図的なのかどうなのでしょうね。

[44] Firefox でも Chrome でも、同じ要素の属性節点同士だと DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC | (DOCUMENT_POSITION_PRECEDING または DOCUMENT_POSITION_FOLLOWING が返されるようです。違う要素の属性ならその所属する要素の関係で決まるようです。

文書順

[6] 「文書順」は通常の DOM 節点に対しては DOM 仕様で定義されていますが、 DOM XPath 仕様では XPathNamespace 節点が追加されているため、それに対応した拡張された「文書順」が定義されています。 DOM XPath に対応している場合には拡張された定義に基づき結果を返さなければなりません >>5。

[7] という規定が2004年の DOM XPath 仕様では compareTreePosition という現存しないメソッド名についてなされていますw

[36] でも、 >>18 の処理モデルは「文書順」の定義を使わずに規定されていますね。

異なる実装からの節点の比較

[9] DOM3 は異なる DOM の実装が混在する環境を扱っています。異なる DOM 実装からの節点の比較であっても、両実装の間で「実装規定」となっている部分の動作について協調して決定できるのであれば、それに従った結果を返すべきであるようです。

[10] 節点が異なる DOM 実装のものであり、「実装規定」の部分について一貫した結果となるよう協調して動作できない場合、例外 NOT_SUPPORTED_ERR を投げます。 >>2

仕様書

引数

返し値

`DocumentPosition`

処理モデル

ビットマスクの決定

文書順

異なる実装からの節点の比較

実装

テスト・ケース

関連