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

Ian Hickson wrote:
> I think it would be difficult to argue that Webkit is not attempting
to 
> implement the Selectors API.

I'm not, but I wasn't talking about Webkit specifically but user-agents
in general.

> > What 
> > I think *is* inside the scope is to ensure that user-agents have
some 
> > unambiguous way to state whether or not they claim to implement the 
> > specification. I think the feature string is much more reliable way
to 
> > do that than checking the existence of a "querySelector" method.
>
> Why would any browser implementor implement one and not the other?

Because they might already be using the "querySelector" method for some
completely unrelated feature. Or, as Sam mentioned on this list, because
they know their implementation is incomplete and don't want to mislead
authors trying to use it. (I would also like to point out that again,
I'm not talking about just browser implementors, but DOM implementors in
general. Web browsers may currently be the largest group there, but they
are not the only ones).

> > If a user-agent decides to implement a "querySelector" method on the

> > Document interface that, say, provides a way to query some godlike 
> > "Selector" creature in a galaxy far away, then there is absolutely
*no* 
> > way for an author to determine whether or not he can call 
> > "querySelector" and expect to return a list of nodes or the meaning
of 
> > life.
>
> What about if a user agent decides to implement a "hasFeature" method
that 
> provides a way to query some godlike "Feature" creature in a galaxy
far 
> away? How can we guarentee that hasFeature() is the right hasFeature()
if 
> we can't guarentee that querySelector() is the right querySelector()?

Given a random object with a hasFeature(), you can't know the
hasFeature() is the right one. However, the DOM 3 Core spec provides a
way (i.e. the DOMImplementationRegistry) to ensure that the "random
object" you have isn't random at all, but that it is in fact a DOM
implementation. Of course, you then ask the same question again - how do
you know the DOMImplementationRegistry object isn't some random one from
a galaxy far away? You have bootstrap the whole process somehow, and the
DOM 3 Core spec admits this problem is unsolvable and explicitly leaves
it to the language binding to do this (section 1.3.7, Bootstrapping).

In the case of the Selectors API, the problem is *not* unsolvable,
simply because assuming you have a DOM implementation, the hasFeature()
method is a reliable way to determine whether or not the "querySelector"
method does what you expect. The bootstrap process is in effect
delegated to the DOM spec.

> I think this is a highly theoretical concern and in practice
hasFeature() 
> is a waste of time and effort (and memory and CPU and bandwidth).

That may be true, and if that's the consensus of the working group, then
I'll accept that. I just think that there is still some value in adding
a feature string, and it's really not that much work. People will
probably use the "if (document.querySelector)" method anyway in
Ecmascript, but it would be nice to at least provide a more reliable and
language-independent method for the cases where this doesn't work. Web
browsers may currently have the only DOM implementations that care about
the Selectors API, but that may not always be the case.

Cheers,
Kartikaya Gupta

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Friday, 15 February 2008 15:14:22 UTC