ビットマスクの決定

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

1. [19] 2節点が同じ節点なら、フラグは何も設定せずに返します。
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。

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

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

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