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

[Lachlan Hunt]

Moving to public-webapps from public-webapi. See original thread here.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg35

João Eiras wrote:
>>  if (document.querySelector) {
>>    // Supported
>>  } else {
>>    // Not suported
>>  }
>
> Too bad that only works with ecmascript.
> Such syntax is not valid in other languages.

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?

Kartikaya Gupta wrote:

> Ian Hickson wrote:
>> Kartikaya Gupta wrote:
>>> 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.

This seems like a very unrealistic edge case, considering we went to a
lot of effort to find names that didn't clash with existing features in
many implementations, not only browsers.

Since I've not seen any support for this proposal from any implementers
at all, and no substantial evidence that people actually make use of
existing feature strings in any environment, I'm not prepared to include
it at this stage.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[João Eiras-2]

> 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.
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.
Else you're locking the Selectors API only to bindings that support
object detection.

(...)

[Kartikaya Gupta-3]

On Wed, 09 Jul 2008 13:32:42 +0200, Lachlan Hunt <lachlan.hunt@...> wrote:

>
> Moving to public-webapps from public-webapi. See original thread here.
> http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg35
>
> João Eiras wrote:
> >>  if (document.querySelector) {
> >>    // Supported
> >>  } else {
> >>    // Not suported
> >>  }
> >
> > Too bad that only works with ecmascript.
> > Such syntax is not valid in other languages.
>
> 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?
>

Speaking as an implementor in Java, I would like to see a feature string defined. I can't provide any evidence that people use feature strings now (largely because existing implementations are in ecmascript where object detection is easier), but without defining a feature string, it would be hard to safely use the Java binding for this feature.

Cheers,
kats

[Lachlan Hunt]

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
http://lachy.id.au/
http://www.opera.com/

[Lachlan Hunt]

Kartikaya Gupta wrote:
> Speaking as an implementor in Java, I would like to see a feature
> string defined. I can't provide any evidence that people use feature
> strings now

Do you use hasFeature() to detect the presence of any other DOM APIs?
If so, when and why?

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Kartikaya Gupta-3]

On Thu, 10 Jul 2008 08:10:09 +0200, Lachlan Hunt <lachlan.hunt@...> wrote:
>
> Kartikaya Gupta wrote:
> > Speaking as an implementor in Java, I would like to see a feature
> > string defined. I can't provide any evidence that people use feature
> > strings now
>
> Do you use hasFeature() to detect the presence of any other DOM APIs?
> If so, when and why?
>

We use feature strings to detect whether or not the DOM implementation supports creating/dispatching certain types of (custom) events. This allows a decoupling of code that uses the DOM with the DOM implementation itself, and allows for independently upgradable components. Some parts of the code also require additional DOM functionality beyond what is provided by the standard APIs. This is exposed via additional interfaces on various DOM objects and feature strings are used to ensure that the DOM provides implementations of these interfaces. Again, this is largely to achieve modularity; it allows the "external" code to be maintained separately rather than tying it to our specific DOM implementation. Hypothetically speaking, if we were to implement something like Gears in Java, it would also be using feature strings extensively to detect the presence or absence of various features.

[Lachlan Hunt]

Kartikaya Gupta wrote:

> On Thu, 10 Jul 2008 08:10:09 +0200, Lachlan Hunt
> <lachlan.hunt@...> wrote:
>> Do you use hasFeature() to detect the presence of any other DOM
>> APIs? If so, when and why?
>
> We use feature strings to detect whether or not the DOM
> implementation supports creating/dispatching certain types of
> (custom) events. This allows a decoupling of code that uses the DOM
> with the DOM implementation itself, and allows for independently
> upgradable components. Some parts of the code also require additional
> DOM functionality beyond what is provided by the standard APIs. This
> is exposed via additional interfaces on various DOM objects and
> feature strings are used to ensure that the DOM provides
> implementations of these interfaces. Again, this is largely to
> achieve modularity; it allows the "external" code to be maintained
> separately rather than tying it to our specific DOM implementation.
> Hypothetically speaking, if we were to implement something like Gears
> in Java, it would also be using feature strings extensively to detect
> the presence or absence of various features.

Would it be acceptable if I defined one, but made it optional for
implementers to support?  Or at least optional for ECMAScript
implementations?  That way an implementation can choose to support it if
feature detection is necessary for the language and there is no other
way to do it.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Kartikaya Gupta-3]

On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt <lachlan.hunt@...> wrote:
>
> Would it be acceptable if I defined one, but made it optional for
> implementers to support?  Or at least optional for ECMAScript
> implementations?  That way an implementation can choose to support it if
> feature detection is necessary for the language and there is no other
> way to do it.
>

Yup, that's fine by me. It ensures that different implementations won't end up using different feature strings for the same feature, if they decide to go that route.

Thanks,
kats

[Boris Zbarsky]

On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt
<lachlan.hunt@...> wrote:
> Would it be acceptable if I defined one, but made it optional for
> implementers to support?  Or at least optional for ECMAScript
> implementations?  That way an implementation can choose to support it if
> feature detection is necessary for the language and there is no other
> way to do it.

What's the point of making the feature string optional, exactly?

-Boris

[Lachlan Hunt]

Boris Zbarsky wrote:
> On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt
> <lachlan.hunt@...> wrote:
>> Would it be acceptable if I defined one, but made it optional for
>> implementers to support?  Or at least optional for ECMAScript
>> implementations?  That way an implementation can choose to support it
>> if feature detection is necessary for the language and there is no
>> other way to do it.
>
> What's the point of making the feature string optional, exactly?

To avoid forcing implementers to bother implementing such a useless
feature, and potentially lying about their support.  Basically, this
should only be for languages other than ECMAScript that don't have other
detection mechanisms available, and where the programmer isn't always in
control of which DOM implementation is in use where the program is run.
  (If the programmer is in control of that, then feature detection is
useless since they can just check the documentation)

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Boris Zbarsky]

Lachlan Hunt wrote:
> To avoid forcing implementers to bother implementing such a useless
> feature, and potentially lying about their support.

But the net result is that some web UAs will implement the feature
string and some won't, which reduces web interoperability....

-Boris

[Sergey Ilinsky]

Lachlan Hunt wrote:

> Boris Zbarsky wrote:
>> On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt
>> <lachlan.hunt@...> wrote:
>>> Would it be acceptable if I defined one, but made it optional for
>>> implementers to support?  Or at least optional for ECMAScript
>>> implementations?  That way an implementation can choose to support
>>> it if feature detection is necessary for the language and there is
>>> no other way to do it.
>> What's the point of making the feature string optional, exactly?
> To avoid forcing implementers to bother implementing such a useless
> feature, and potentially lying about their support.  Basically, this
> should only be for languages other than ECMAScript that don't have
> other detection mechanisms available, and where the programmer isn't
> always in control of which DOM implementation is in use where the
> program is run.  (If the programmer is in control of that, then
> feature detection is useless since they can just check the documentation)

Lachlan, shall the "Events" feature string be dropped from Events module
then as well? The Events (Level-3) is now a working draft, so it could
be a good moment of time to doing so!

In case it is not going to be dropped, then there is no sense to not
including "Selectors" feature string in the "Selectors API"
specification, given the fact that every other DOM module is required to
provide one (correct me if I am wrong).

Also, could it be a good idea to contact great people who have set up
the DOM-family specifications for use cases they had in mind with the
DOM modules' "featuring" features.

Sergey Ilinsky/

[Maciej Stachowiak]

On Jul 14, 2008, at 8:15 AM, Lachlan Hunt wrote:

>
> Boris Zbarsky wrote:
>> On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt <lachlan.hunt@...
>> > wrote:
>>> Would it be acceptable if I defined one, but made it optional for  
>>> implementers to support?  Or at least optional for ECMAScript  
>>> implementations?  That way an implementation can choose to support  
>>> it if feature detection is necessary for the language and there is  
>>> no other way to do it.
>> What's the point of making the feature string optional, exactly?
>
> To avoid forcing implementers to bother implementing such a useless  
> feature, and potentially lying about their support.  Basically, this  
> should only be for languages other than ECMAScript that don't have  
> other detection mechanisms available, and where the programmer isn't  
> always in control of which DOM implementation is in use where the  
> program is run.  (If the programmer is in control of that, then  
> feature detection is useless since they can just check the  
> documentation)

Since implementing the feature string is trivial, I'd rather it be  
mandatory. I agree that feature strings are not a great mechanism, but  
optional features are a greater harm than feature strings.

Regards,
Maciej

[Anne van Kesteren-2]

On Mon, 14 Jul 2008 20:26:23 +0200, Maciej Stachowiak <mjs@...>  
wrote:
> Since implementing the feature string is trivial, I'd rather it be  
> mandatory. I agree that feature strings are not a great mechanism, but  
> optional features are a greater harm than feature strings.

When I originally proposed this to Lachlan I suggested making it a feature  
for non-ECMAScript implementations. I agree that making it optional is not  
good.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Lachlan Hunt]

Maciej Stachowiak wrote:

> On Jul 14, 2008, at 8:15 AM, Lachlan Hunt wrote:
>> To avoid forcing implementers to bother implementing such a useless
>> feature, and potentially lying about their support.  Basically, this
>> should only be for languages other than ECMAScript that don't have
>> other detection mechanisms available, and where the programmer isn't
>> always in control of which DOM implementation is in use where the
>> program is run.  (If the programmer is in control of that, then
>> feature detection is useless since they can just check the documentation)
>
> Since implementing the feature string is trivial, I'd rather it be
> mandatory.

I have now added a mandatory feature string.

http://dev.w3.org/2006/webapi/selectors-api/#dom-feature

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Lachlan Hunt]

Lachlan Hunt wrote:
> I have now added a mandatory feature string.
>
> http://dev.w3.org/2006/webapi/selectors-api/#dom-feature

It's been suggested to me that the spec should say something about
support for the other methods that use feature strings, including:

interface DOMImplementationSource {
   DOMImplementation  getDOMImplementation(in DOMString features);
   DOMImplementationList getDOMImplementationList(in DOMString features);
};
interface DOMImplementation {
   boolean            hasFeature(in DOMString feature,
                                 in DOMString version);
   DOMObject          getFeature(in DOMString feature,
                                 in DOMString version);
};
interface Node {
   boolean            isSupported(in DOMString feature,
                                  in DOMString version);
   DOMObject          getFeature(in DOMString feature,
                                 in DOMString version);
};

I'm not sure what exactly I should say about them, nor really understand
the purpose of them. But they're in DOM3Core and will need to be tested
in the test suite.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Anne van Kesteren-2]

On Tue, 19 Aug 2008 16:35:52 +0200, Lachlan Hunt  
<lachlan.hunt@...> wrote:

> Lachlan Hunt wrote:
>> I have now added a mandatory feature string.
>>  http://dev.w3.org/2006/webapi/selectors-api/#dom-feature
>
> It's been suggested to me that the spec should say something about  
> support for the other methods that use feature strings, including:
>
> interface DOMImplementationSource {
>    DOMImplementation  getDOMImplementation(in DOMString features);
>    DOMImplementationList getDOMImplementationList(in DOMString features);
> };
> interface DOMImplementation {
>    boolean            hasFeature(in DOMString feature,
>                                  in DOMString version);
>    DOMObject          getFeature(in DOMString feature,
>                                  in DOMString version);
> };
> interface Node {
>    boolean            isSupported(in DOMString feature,
>                                   in DOMString version);
>    DOMObject          getFeature(in DOMString feature,
>                                  in DOMString version);
> };
>
> I'm not sure what exactly I should say about them, nor really understand  
> the purpose of them. But they're in DOM3Core and will need to be tested  
> in the test suite.

Maybe just reference DOM Level 2 Core? There's a lot in DOM Level 3 Core  
that's not really implemented yet or necessarily desirable.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Lachlan Hunt]

Lachlan Hunt wrote:

> It's been suggested to me that the spec should say something about
> support for the other methods that use feature strings, including:
>
> interface DOMImplementationSource {
>   DOMImplementation  getDOMImplementation(in DOMString features);
>   DOMImplementationList getDOMImplementationList(in DOMString features);
> };
> ...
>
> I'm not sure what exactly I should say about them, nor really understand
> the purpose of them. But they're in DOM3Core and will need to be tested
> in the test suite.

I ended up dealing with this issue by making the DOM feature string
section more generic, mostly deferring to DOM3 for applicable
conformance criteria.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/