Re: [selectors-api] What DOM feature Selectors API belongs to?
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/
Re: [selectors-api] What DOM feature Selectors API belongs to?
On Tue, 19 Aug 2008 16:35:52 +0200, Lachlan Hunt
[EMAIL PROTECTED] 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 {
booleanhasFeature(in DOMString feature,
in DOMString version);
DOMObject getFeature(in DOMString feature,
in DOMString version);
};
interface Node {
booleanisSupported(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/
Re: [selectors-api] What DOM feature Selectors API belongs to?
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 [EMAIL PROTECTED] 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
Re: [selectors-api] What DOM feature Selectors API belongs to?
On Mon, 14 Jul 2008 20:26:23 +0200, Maciej Stachowiak [EMAIL PROTECTED] 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/
Re: [selectors-api] What DOM feature Selectors API belongs to?
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/
Re: [selectors-api] What DOM feature Selectors API belongs to?
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/
Re: [selectors-api] What DOM feature Selectors API belongs to?
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. (...)
Re: [selectors-api] What DOM feature Selectors API belongs to?
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/
