[3] Node
オブジェクトの compareDocumentPosition
メソッドは、2つの節点の文書順的な意味での関係を返します。
[4] 現時点では Web DOM Core には存在することだけで実質的な規定がまだされていません。
[17] このメソッドは2節点間の関係を表すビットマスクを返します。データ型としては
unsigned short
です >>2。
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] このメソッドがよばれた節点を参照節点とするとき、 参照節点と第1引数に与えられた節点についての文書中での位置を文書順に基づき調べてビットマスクとして返します >>2。
[18] このメソッドは2節点間の文書中の相対位置を表すビットマスクを返します。 この値は次のようにして決定されます。 >>13
[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
[39] 要素の包含関係を調べるメソッドには他に contains
があります。
contains
は compareDocumentPosition
とは違って同じ要素 (自分自身) は「含んでいる」と判断します。
[40] 要素の順序は sourceIndex
属性の値の比較でも求められます。
[42] IRC logs: freenode / #whatwg / 20121015 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20121015#l-365>
[45] Make Attr inherit from Node again (annevk著, ) <https://github.com/whatwg/dom/commit/625a0747f137454c155a7b577a9e45be1aa35a34>
[46] Further Attr node fixes for compareDocumentPosition() (annevk著, ) <https://github.com/whatwg/dom/commit/0e17e05b7b0273799b853c4782b2eac9a88fdea1>
compareTreePosition
という現存しないメソッド名についてなされていますw