- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Fri, 15 Feb 2008 00:22:38 +0100
- To: Sam Weinig <weinig@apple.com>
- CC: Sergey Ilinsky <castonet@yahoo.co.uk>, public-webapi@w3.org
Sam Weinig wrote: > Sergey, > >> And as for Safari. Yes, it does have document.querySelector, but! >> because of some reason it doesn't have >> DocumentSelector/ElementSelector objects exposed, it doesn't return >> StaticNodeList from document.querySelectorAll, so, the question is - >> does it now support "Selectors API"? Your answer is "yes". mine, >> according to your specification - no. > > I am curious as to why think there should be > DocumentSelector/ElementSelector objects exposed in a conforming UA. > The spec states: 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. > 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. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Thursday, 14 February 2008 23:22:52 UTC