On Fri, 15 Feb 2008 00:22:38 +0100, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
The assumption probably arises from the fact that many of the DOM2
interfaces, such as Document, Element, Node, etc. are exposed like that.
While it makes sense for some of those because, for example, the have
constants defined for them (e.g. Node.ELEMENT_NODE) or because it allows
for their prototypes to be extended (e.g. Element.prototype), the value
of exposing them for selectors api is questionable at best.
Indeed. In another thread I requested functionality to be added to DOM
Bindings so you could indicate whether the interface is exposed or not or
way to define what the "base" interface it is which has the same effect
but might be cleaner as it also removes the need to say "objects
implementing interface X must also implement interface XY".
Regarding the returning a StaticNodeList, the implementation in Safari
returns an object that implements the StaticNodeList interface, though
that happens to be the same as the NodeList interface. One potential
issue here is that we don't expose a StaticNodeList constructor on the
window (window.StaticNodeList) but instead use the NodeList's
constructor.
Given that, I believe it would be better if the spec was more honest
about this issue by simply stating that an object implementing the
NodeList interface is returned, but that the list is not live. I will
consider making that change soon.
Yeah, we should drop StaticNodeList and add a note that DOM Level 3 Core
saying NodeList is "live" is a bug.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
