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

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

From: Kartikaya Gupta <kagupta@rim.com>
Date: Thu, 14 Feb 2008 15:00:47 -0500
Message-ID: <24BE9C481C439C48831EB9E52639B9B60A8D4842@XCH42YKF.rim.net>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Sergey Ilinsky" <castonet@yahoo.co.uk>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, <public-webapi@w3.org>

Ian Hickson wrote:
> On Thu, 14 Feb 2008, Kartikaya Gupta wrote:
> > Ian Hickson wrote:
> > > On Thu, 14 Feb 2008, Kartikaya Gupta wrote:
> > > >
> > > > If a user-agent returns "true" from hasFeature() without
> > > > providing a conforming implementation of the feature, then
that's a 
> > > > bug in the user-agent, no?
> > >
> > > Sure. So's the fact that it doesn't have a conforming
> > > in the first place. Bugs are common.
> > 
> > That's only a bug if they /claim/ to have a conforming
> No, it's a bug either way. A bug is something that doesn't match the
> the spec doesn't change based on whether the browser claims to
> it or not.

Is it just me, or does seem very wrong? That means I can claim every
piece of software in the world is buggy, because none of them implement
a spec I just made up.

I would consider a bug to be something doesn't match the spec IF it's
*supposed* to match the spec. If it doesn't claim to match the spec,
then you're right, that doesn't change the spec. It does, however,
change what should be considered bugs in the software and what shouldn't
(i.e. it's a feature, not a bug).

I also agree with you in that the spec shouldn't care if implementations
have bugs. There may be bugs in the querySelector implementation, or
there may be bugs in the hasFeature implementation, or both. Making an
implementation bug-free is outside the scope of the specification. 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.

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. In such a scenario, the only reasonable thing for the author to do
is to not use "querySelector" at all and just iterate through the DOM to
find the nodes himself. That doesn't seem like a very useful
specification to me.

I'd also like to point out that a large part of this problem is just a
namespace issue - if the method had been called
"org.w3c.dom.querySelector" I wouldn't have a problem with it, because
that wouldn't conflict with "com.galaxyfaraway.querySelector". It's the
high potential for conflicts here that seems wrong. Feature strings for
vendor-specific extension should be properly namespaced and greatly
reduce the chance for such a conflict.

> > That sets a very dangerous precedent where other specifications
> > reserve other method names and greatly reduce the freedom for 
> > user-agents to provide vendor-specific/proprietary DOM extensions.
> Indeed, this is common practice. For example, CSS has reserved every 
> identifier that doesn't start with a hyphen.

But they do so explicitly. I might be missing something, but I don't
think the DOM specification says "user agents MUST NOT provide methods
in addition to the ones specified here". In fact, it says quite the
opposite: additional methods are welcome, and official support for such
features should be indicated via hasFeature(). Also with the CSS
example, there is a feature string for CSS that allows authors to
determine whether or not a user-agent follows this practice or not, and
whether they can reasonably expect "html { color: red }" to work as they
think it will.

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 Thursday, 14 February 2008 20:01:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC