Re: [selectors-api] Investigating NSResolver Alternatives
This is moot now that NSResolver is gone from selector-api, but… Boris Zbarsky: The way I see it, all current impls should throw something if more than one arg is passed Lachlan Hunt: Which exception should be thrown? Is this something I should define in this spec, or is it something for WebIDL or some other spec to deal with? Boris Zbarsky: Honestly, I don't care much on that point. Anne van Kesteren: FWIW, I consider it to be a Web IDL issue as it affects every interface. (HTML5 currently has explicit text for this (to have additional arguments be ignored) but expects it to move into Web IDL.) The rewritten Operations section of the ECMAScript binding now ignores additional arguments: http://dev.w3.org/2006/webapi/WebIDL/#es-operations Passing fewer arguments than required results in a TypeError. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [selectors-api] Investigating NSResolver Alternatives
Lachlan Hunt wrote: The way I see it, all current impls should throw something if more than one arg is passed Which exception should be thrown? Is this something I should define in this spec, or is it something for WebIDL or some other spec to deal with? Honestly, I don't care much on that point. -Boris
Re: [selectors-api] Investigating NSResolver Alternatives
Lachlan Hunt wrote: The developers implementing this in Opera has given me feedback saying that this shouldn't throw an exception because JS allows additional arguments to be passed to any method, including other DOM APIs, like getElementById(), etc. Is there a good reason why this should behave differently? Well, it depends on whether you plan to add arguments in the future. If you don't then it doesn't matter that extra arguments don't throw. But if you do add arguments later, and pages are passing extra arguments and expecting that to not throw, then that either constrains what you can do with the arguments you add (e.g. they must never throw, no matter what) or you force UAs to break pages. So the suggestion that extra arguments should throw in this case is based on the assumption that you plan to add some sort of argument for namespaces later and the assumption that throwing on extra arguments now is better than the two alternatives in the previous paragraph. Of course not throwing on extra arguments is indeed the easy path to implementation (and is what Gecko will be shipping, it looks like), so as long as you can live with the results as a spec writer it's all good by me. -Boris
Re: [selectors-api] Investigating NSResolver Alternatives
Boris Zbarsky wrote: Lachlan Hunt wrote: The developers implementing this in Opera has given me feedback saying that this shouldn't throw an exception because JS allows additional arguments to be passed to any method, including other DOM APIs, like getElementById(), etc. Is there a good reason why this should behave differently? Well, it depends on whether you plan to add arguments in the future. If you don't then it doesn't matter that extra arguments don't throw. But if you do add arguments later, and pages are passing extra arguments and expecting that to not throw, then that either constrains what you can do with the arguments you add (e.g. they must never throw, no matter what) or you force UAs to break pages. So the suggestion that extra arguments should throw in this case is based on the assumption that you plan to add some sort of argument for namespaces later and the assumption that throwing on extra arguments now is better than the two alternatives in the previous paragraph. Of course not throwing on extra arguments is indeed the easy path to implementation (and is what Gecko will be shipping, it looks like), so as long as you can live with the results as a spec writer it's all good by me. I think we should follow suite with all other functions in the DOM, which means we should not throw for extra arguments. I see no reason to treat this function differently than everything else. / Jonas
Re: [selectors-api] Investigating NSResolver Alternatives
On Wed, 20 Aug 2008 08:26:30 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: The way I see it, all current impls should throw something if more than one arg is passed Which exception should be thrown? Is this something I should define in this spec, or is it something for WebIDL or some other spec to deal with? Honestly, I don't care much on that point. FWIW, I consider it to be a Web IDL issue as it affects every interface. (HTML5 currently has explicit text for this (to have additional arguments be ignored) but expects it to move into Web IDL.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Investigating NSResolver Alternatives
Jonas Sicking wrote: Boris Zbarsky wrote: Of course not throwing on extra arguments is indeed the easy path to implementation (and is what Gecko will be shipping, it looks like), so as long as you can live with the results as a spec writer it's all good by me. I think we should follow suite with all other functions in the DOM, which means we should not throw for extra arguments. I see no reason to treat this function differently than everything else. OK, agreed. No exceptions for extra arguments. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Investigating NSResolver Alternatives
Unfortunately I don't think we can change how XPath parses things since there is already code out there that might rely on the current behavior. Might be worth looking into though. I don't want to worry about xpath, although that misfeautre bite me hard :) Chaging the behavior how I suggested would be harmless because currently, the use cases I wanted to fix either had the behavior unspecified or exceptions were expected to be thrown. My concearn currently is with the selectors-api. I don't want to see the same errors repeated. Bye.
Re: [selectors-api] Investigating NSResolver Alternatives
João Eiras wrote: Unfortunately I don't think we can change how XPath parses things since there is already code out there that might rely on the current behavior. Might be worth looking into though. I don't want to worry about xpath, although that misfeautre bite me hard :) Chaging the behavior how I suggested would be harmless because currently, the use cases I wanted to fix either had the behavior unspecified or exceptions were expected to be thrown. My concearn currently is with the selectors-api. I don't want to see the same errors repeated. Agreed. I think the right solution is to make the changes you have proposed to NSResolver, and then make use of the NSResolver interface for the querySelector(All) APIs. / Jonas
Re: [selectors-api] Investigating NSResolver Alternatives
Hi ! I vote for having a new light weight object to completely replace the current NSResolver, and then apply it to other DOM specs namely the XPath DOM. I had some of the problems we're discussing with the XPath DOM API, and obviously the same apply here. I exposed my problems at the dom mailing list, but my comments were dismissed completely http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html The problems I outlineed with NSResolver are summarized to the following: - a element with no prefix is assumed to be in the namespace with null uri. You can't change this behavior. - a element with a prefix MUST be in a namespace with non null namespace uri, else returning empty string from lookupNamespaceURI results in NAMESPACE_ERR being thrown I proposed the following changes: - a element with no prefix would result in lookupNamespaceURI being called with the empty string, and the resolver could return a default namespace, or return null (or empty string) to imply the null namespace - a element with prefix would result in lookupNamespaceURI being called with the prefix and the function could either return null (or empty string) to imply the null namespace, or it could return a fully qualified uri. These changes fitted well with the specification because these cases were either undefined or expected implementations to simply throw exceptions. I ask you not to make the same mistakes that were done with the xpath dom api, because nsresolver currently is fairly broken, and not that much useful. Again, I vote for a new lightweight object, and to allow mixing both elements with or without prefixies with null or non null namespace uris. Thank you.
Re: [selectors-api] Investigating NSResolver Alternatives
João Eiras wrote:
Hi !
I vote for having a new light weight object to completely replace the
current NSResolver, and then apply it to other DOM specs namely the
XPath DOM.
I had some of the problems we're discussing with the XPath DOM API, and
obviously the same apply here.
I exposed my problems at the dom mailing list, but my comments were
dismissed completely
http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html
The problems I outlineed with NSResolver are summarized to the following:
- a element with no prefix is assumed to be
in the namespace with null uri. You can't
change this behavior.
This is not true. We can just define that unprefixed names call into the
NSResolver with an empty string, and whatever the NSResolver returns
will be used as prefix.
- a element with a prefix MUST be in a
namespace with non null namespace uri, else
returning empty string from lookupNamespaceURI
results in NAMESPACE_ERR being thrown
Again, this is not true. We can just define that returning the empty
string means to use the null namespace.
null is the value that's supposed to be returned when no namespace is
found and NAMESPACE_ERR should be thrown.
Even the resolver returned from createNSResolver is horribly
underdefined and so we could make it follow the above rules without
breaking any specs.
I proposed the following changes:
- a element with no prefix would result in
lookupNamespaceURI being called with the empty
string, and the resolver could return a default
namespace, or return null (or empty string) to
imply the null namespace
- a element with prefix would result in
lookupNamespaceURI being called with the prefix
and the function could either return null
(or empty string) to imply the null namespace,
or it could return a fully qualified uri.
Having to create an element whenever you want to resolve some custom
namespaces seems like a horrible hack, and awefully complicated to use.
Say that I wanted to find all elements in the myNS namespace, using a
NSResolver I would do:
doc.querySelectorAll(*, function (pre) {
return pre == ? myNS : null;
});
With your proposed solution I'd have to do
doc.querySelectorAll(*,
document.createElementNS(myNS, dummy));
This looks sort of ok, but still very strange to have to use the dummy
name. However, if i'm using two namespaces in an expression i'm in a
world of pain. Compare
doc.querySelectorAll(a:*, b:*, function (pre) {
return pre == a ? myNS :
pre == b ? myNS2 : null;
});
vs
e = document.createElement(dummy);
e.setAttributeNS(http://www.w3.org/2000/xmlns/;,
xmlns:a, myNS)
e.setAttributeNS(http://www.w3.org/2000/xmlns/;,
xmlns:b, myNS2)
doc.querySelectorAll(a:*, b:*, e);
How many people even know the proper namespace for the xmlns attribute?
Did you?
On top of that we can't really change how DOM-XPath works given that
there are implementations for the spec with pages out there depending on it.
/ Jonas
Re: [selectors-api] Investigating NSResolver Alternatives
João Eiras wrote: On , Jonas Sicking [EMAIL PROTECTED] wrote: João Eiras wrote: Hi ! I vote for having a new light weight object to completely replace the current NSResolver, and then apply it to other DOM specs namely the XPath DOM. I had some of the problems we're discussing with the XPath DOM API, and obviously the same apply here. I exposed my problems at the dom mailing list, but my comments were dismissed completely http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html The problems I outlineed with NSResolver are summarized to the following: - a element with no prefix is assumed to be in the namespace with null uri. You can't change this behavior. This is not true. We can just define that unprefixed names call into the NSResolver with an empty string, and whatever the NSResolver returns will be used as prefix. - a element with a prefix MUST be in a namespace with non null namespace uri, else returning empty string from lookupNamespaceURI results in NAMESPACE_ERR being thrown Again, this is not true. We can just define that returning the empty string means to use the null namespace. null is the value that's supposed to be returned when no namespace is found and NAMESPACE_ERR should be thrown. Even the resolver returned from createNSResolver is horribly underdefined and so we could make it follow the above rules without breaking any specs. You misread. That was the list of issues I outlined on the dom mailing list, back in 2007. Of course we can workaround them, and we should. I proposed the following changes: - a element with no prefix would result in lookupNamespaceURI being called with the empty string, and the resolver could return a default namespace, or return null (or empty string) to imply the null namespace - a element with prefix would result in lookupNamespaceURI being called with the prefix and the function could either return null (or empty string) to imply the null namespace, or it could return a fully qualified uri. Having to create an element whenever you want to resolve some custom namespaces seems like a horrible hack, and awefully complicated to use. Having what ? Since when did I suggest creating elements ? That list of suggestions were about chaging NSResolver behavior. Doh! I got to the a element part and then misread the rest with faulty assumptions. My bad. I agree with the above. You may go to http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html for code samples. Unfortunately I don't think we can change how XPath parses things since there is already code out there that might rely on the current behavior. Might be worth looking into though. / Jonas
Re: [selectors-api] Investigating NSResolver Alternatives
Boris Zbarsky wrote: Lachlan Hunt wrote: Given that IE, Webkit and Opera seem to be in favour of dropping NSResolver, if Mozilla will agree, I'm more than happy to do so OK. We talked it over, and this sounds like the best way going forward for now. I have stripped all requirements from the spec relating to resolving namespace prefixes using an NSResolver. Although it still has the requirement to throw a NAMESPACE_ERR when namespace prefixes that need to be resolved are encountered and still allows for *|div and |div to be used. http://dev.w3.org/2006/webapi/selectors-api/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Investigating NSResolver Alternatives
On Wed, 16 Jul 2008 13:43:06 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: I have stripped all requirements from the spec relating to resolving namespace prefixes using an NSResolver. Although it still has the requirement to throw a NAMESPACE_ERR when namespace prefixes that need to be resolved are encountered and still allows for *|div and |div to be used. http://dev.w3.org/2006/webapi/selectors-api/ In theory it might be better to throw NOT_SUPPORTED_ERR so going forward you can distinguish between the case where namespaces are not supported and the case where they are, but you forgot to bind a prefix to a namespace. (Take into account that Web IDL might define additional arguments to be ignored, as HTML5 currently suggests, and that the namespace binding mechanism might be out of bound.) Having said that, it probably doesn't matter much. :-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Investigating NSResolver Alternatives
Lachlan Hunt wrote: Although it still has the requirement to throw a NAMESPACE_ERR when namespace prefixes that need to be resolved are encountered http://dev.w3.org/2006/webapi/selectors-api/ In theory it might be better to throw NOT_SUPPORTED_ERR so going forward you can distinguish between the case where namespaces are not supported and the case where they are, but you forgot to bind a prefix to a namespace. Done. Uh... wait a sec. If there is no NSResolver or equivalent and prefixes are used, that's forgetting to bind a prefix to a namespace (and should get NAMESPACE_ERR). What cases are we trying to distinguish here, exactly? The way I see it, all current impls should throw something if more than one arg is passed, and should throw NAMESPACE_ERR if a prefix needs to be resolved. -Boris
Re: [selectors-api] Investigating NSResolver Alternatives
Lachlan Hunt wrote: Given that IE, Webkit and Opera seem to be in favour of dropping NSResolver, if Mozilla will agree, I'm more than happy to do so OK. We talked it over, and this sounds like the best way going forward for now. -Boris
Re: [selectors-api] Investigating NSResolver Alternatives
On Mon, 14 Jul 2008 21:30:18 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: How do I select all the inline SVG images on the page? div svg, p svg though it's not quite as thorough as your solution. Offhand, you're missing td, span, body to cover any sort of decent range of images But yes, much less thorough, indeed. And hard to get right. True. On the other hand, this seems extremely complex to author and not something most authors would come up. :-) That's possible, but I would think that the authoring of the query would be by one of the various toolkits, and the author would call getSVGImages() or some such. Ok. If this is the kind of scenario we're trying to get NSResolver defined for it does not be worth it. Last I checked, the main envisioned use of the querySelector* APIs was to speed up existing queries toolkits do. Might be worth asking them what they think would be useful. http://krijnhoetmer.nl/irc-logs/whatwg/20080709#l-597 http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.query (It doesn't even do XML unless all names are lowercase.) http://www.prototypejs.org/api/utility/dollar-dollar I agree that asking them explicitly would be good though, but it seems like so far the need was not compelling enough to implement it. (And libraries generally have gone to extreme lengths to implement other things not natively supported by browsers or not available cross browser.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
