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

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

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 14 Feb 2008 19:15:53 +0000 (UTC)
To: Kartikaya Gupta <kagupta@rim.com>
Cc: Sergey Ilinsky <castonet@yahoo.co.uk>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi@w3.org
Message-ID: <Pine.LNX.4.62.0802141910150.20115@hixie.dreamhostps.com>

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 actually 
> > > 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 implementation 
> > in the first place. Bugs are common.
> 
> That's only a bug if they /claim/ to have a conforming implementation.

No, it's a bug either way. A bug is something that doesn't match the spec; 
the spec doesn't change based on whether the browser claims to implement 
it or not.


> My point (which is what I think Sergey was trying to say) is that the 
> Selectors API specification can't arbitrarily reserve the 
> "querySelector" method name and declare that any DOM implementation that 
> has such a method implements the spec.

Sure it can. That's how the Web and the W3C work.


> That sets a very dangerous precedent where other specifications could 
> 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.


> The Selectors API *can* however reserve a feature string, because that's 
> the entire point of the feature strings in the first place.

The entire point of the DOM in the first place is to provide a consistent, 
interoperable API on all browsers.


But this is besides the point, the point is that a browser vendor doesn't 
necessarily know whether it has bugs or not. The easiest thing to 
implement is hasFeature(), therefore that will likely be done long before 
all the unknown bugs in the actual feature are flushed out.

Also, how do you draw the line? What about if querySelector() works with 
everything except documents that are exactly 23,895,472 bytes long? In the 
unlikely event that this bug is found, should hasFeature() stop returning 
true? When can a browser know to make hasFeature() return true?

Bugs are common. You can't rely on one part of the API (hasFeature) not 
having bugs to work around other bugs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 14 February 2008 19:16:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2008 19:16:03 GMT