「NodeListがliveなものを返すってDOM3 Coreのバグじゃね？」と言われているのはなんで？

DOM

querySelectorAllがliveじゃないNodeList返すのはなんで？ - vantguarde - web:gからの話なのですが、気になったので調べています。

今のところ「NodeListがliveなものを返すってDOM3 Coreのバグじゃね？」と言われている理由の予想としてはこんな感じかな、と思います。

  • liveで嬉しいことがあまりないこと((liveで嬉しいことをどなたかいろいろ教えていただけると嬉しいです。自分としては「過去の慣習」、「getElementsByTagName()等の呼び出しが一回ですむ」、「childNodesを親Nodeから切り離しても切り離さなくても同じように扱える」くらいのものしか思いつきませんでした))
  • 実装にかかる時間(実装者の問題)
  • 処理速度(実装者、スクリプト作成者、ユーザーの問題)
  • 繰り返し構文+インデックスアクセスでのDOM木への追加または削除のケース等で混乱を招きやすい(スクリプト作成者の問題)
  • 仕様に使いにくい(策定者の問題)

仕様に使いにくいというのは、今のNodeListは「DOM木の変更によって自動更新されるNodeの文書順リスト」*1なので単に「Nodeの(文書順)リスト」として使いたい仕様の場合(例えば高度な検索条件を指定して結果をリストとして返すような仕様の場合、主に軽量機器向けの仕様の場合)、NodeListを敬遠せざるを得ないということです。もし単に「Nodeの(文書順)リスト」というだけであればDOM XPathはもう少し不細工でないように出来たんじゃないかと思います(Element Traversalなんかも？)。

Selectors APIのquerySelectorAll()のNodeListをliveにする場合は、擬似クラス(特に:hoverや:active)のことを考えると最悪「DOM木の変更とユーザーアクション(ポインティングデバイスの移動等)によって自動更新されるNodeの文書順リスト」になってしまって、スクリプト作成者にさらなる混乱を与えることになるかもしれません。また、CSS3セレクタはXPathには及びませんが、さまざまなセレクタやグループ化によって十分に複雑な検索が可能ですから速度的な面も心配です。

このままだと今後NodeListを嫌った高レイヤーの仕様が軒並み不細工になっていくおそれがあるので、今後のことを考えるとNodeList自体をデフォルトをstaticにしてオプションでliveにした方が良いような感じがします。

メモ*2

バグ発言関連
Element Traversal, SVG Tiny 1.2

*1:http://www.w3.org/TR/DOM-Level-3-Core/core.html#td-live等。あれ、ordered listsとはあるけどdocument order云々とは書いてないんですね。文書順じゃない順序つきのNodeListって何かあったかな…

*2:偏向有