W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

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

From: Sam Weinig <weinig@apple.com>
Date: Thu, 14 Feb 2008 13:03:22 -0800
To: Sergey Ilinsky <castonet@yahoo.co.uk>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi@w3.org
Message-id: <6582A71D-C8A5-4BB8-A379-9B187A5E3F0F@apple.com>

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:

> Objects implementing the Document interface, as defined in DOM Level  
> 3 Core, must also implement the DocumentSelector interface. Likewise  
> objects implementing the Element interface, as defined in DOM Level  
> 3 Core, must also implement the ElementSelector interface.


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.

All that said, if there was a feature string for the Selectors API, as  
it stands now, WebKit would not return true as we don't fully support  
the specification yet in that we don't support the NSResolver versions  
of the query functions.

-Sam
Received on Friday, 15 February 2008 15:09:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 February 2008 15:09:36 GMT