Re: [selectors-api] What DOM feature "Selectors API" belongs to?

On Fri, 15 Feb 2008 00:22:38 +0100, Lachlan Hunt  
<lachlan.hunt@lachy.id.au> 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/>

Received on Thursday, 14 February 2008 23:28:56 UTC