W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 09 Jul 2008 15:59:28 +0200
Message-ID: <4874C440.3090708@lachy.id.au>
To: João Eiras <joao.eiras@gmail.com>
Cc: public-webapps <public-webapps@w3.org>

João Eiras wrote:
>> Is there really any demand from implementers of other languages to have a
>> feature sting defined for hasFeature()?  Is there any evidence that people
>> make use of existing feature strings in their programs, using any
>> implementation?
> You provide a feature, then others use it, not the other way around.
> Ecmascript (javascript) programmers go directly for object detection
> because it's simpler.

In this case, hasFeature() has existed for a while with various strings 
that can be used to detect other DOM APIs.  My question was whether or 
not these other existing feature strings are used for such detection 
anywhere, in any language or implementation.  If so, then that would 
serve as useful evidence supporting the addition of a feature string to 
Selectors API.  If, however, hasFeatures is not used for any other 
features, then there's little evidence that it would be used for 
selectors api either.

> Still, the entire DOM spec has Java bindings, and one never knows, but
> in the future we can have other programming languages with DOM
> bindings, which can be used either in a browser or another kind of
> program that renders html/xml. Supporting hasFeature is about being
> forwards compatible.

Vague hypothetical future scenarios do not serve as useful evidence.  If 
the need ever arises for such feature detection to be incorporated into 
a future language, we can come back and take another look at the issue 
in a future version of the specification.

Lachlan Hunt - Opera Software
Received on Wednesday, 9 July 2008 14:00:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC