Re: [selectors-api] querySelector with namespace
On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote: Jonathan Watt wrote: Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. That's because you're not reading what Jonathan has been saying. He said xml:id was just the example that drew his attention to the fact that the selectors API can't do namespaces. He points out, rather correctly, that there is no reason that Web content shouldn't be able to process XML and present the processed information to the user. The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Not supporting prefix resolution in selectors is silly, and so far I have yet to see a reason not to do it that isn't grounded in religion. -- Robin Berjon - http://berjon.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote: Jonathan Watt wrote: Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. That's because you're not reading what Jonathan has been saying. He said xml:id was just the example that drew his attention to the fact that the selectors API can't do namespaces. Yes, I know what he said. The point is that since he agrees that xml:id can't be used in practice on the web, and because even if it could, the ID selector would be good enough, it's not really a compelling, real-world use case for *why* namespace resolution is needed. And other than xml:id, he didn't clearly describe any other use cases at all. He points out, rather correctly, that there is no reason that Web content shouldn't be able to process XML and present the processed information to the user. The question is not and should not be about proving why it shouldn't be able to process XML with namespaces. The question is about why is it worth spending any more time, money and effort than we already have developing a solution for namespace prefix resolution? That is the question that namespace proponents have continually failed to address, and is why I have so far not deemed the issue worthy of significantly more of my time. The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Please clearly explain what one of those real-world things are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
On Nov 30, 2009, at 15:38 , Lachlan Hunt wrote: The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Please clearly explain what one of those real-world things are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing. Well, the fact of the matter is that no matter how much energy one might spend pointing out the issues, you'll still come back and say that we don't have a case where the problems are significant enough to be worth addressing. So where do we go from here? There are quite a few services out there that return XML — it would be disingenuous to pretend otherwise. The addition of x-site requests to the stack makes these even more available. XHR supports XML natively, including namespace. Selectors support namespaces natively. Implementations already support that — exposing it at the API level is hardly a massive cost. So apart from saying that all of these are wrong, or saying that XML, XHR, Selectors aren't part of the web stack I can hardly see where your argument is going. Some people did try to specify over-engineered and useless mechanisms based on getting prefixes from a Node. I've been tracking this since this group exists, and I have yet to see a convincing argument that it can't be done simply. Show me a case in which there is a genuine issue, and we might have an informed discussion. -- Robin Berjon - http://berjon.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: There are quite a few services out there that return XML — it would be disingenuous to pretend otherwise. The addition of x-site requests to the stack makes these even more available. XHR supports XML natively, including namespace. Selectors support namespaces natively. Implementations already support that — exposing it at the API level is hardly a massive cost. So apart from saying that all of these are wrong, or saying that XML, XHR, Selectors aren't part of the web stack I can hardly see where your argument is going. No-one is disputing the fact that those tools exist and that they could be used for XML with namespaces. But are those tools being used in ways that utilise namespaces in useful ways, such that having them exposed at the selector API level would be either useful or even necessary? How about we take a look at some public website APIs using XML that could be suitable for use in cross site requests, and see which, if any, could possibly benefit from supporting prefixes in this API? Twitter: http://apiwiki.twitter.com/Twitter-API-Documentation Does not use namespaces at all, would not benefit from it being added to this API. Flickr: http://www.flickr.com/services/api/ Again, does not use namespaces at all. Validator.nu: http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface http://wiki.whatwg.org/wiki/Validator.nu_XML_Output This does use namespaces in the XML version of it's API. It nests fragments of the XHTML markup within the message and extract elements. These tag names don't clash with any in XHTML, and so they can be selected without bothering about namespaces, or by using a selector like messageserrorelaboration To select any of the XHTML itself, it's easy enough to use a selector like: errorelaboration div or infomessage code The source element does clash with the source element in HTML5, but it can be easily and unambiguously selected using messagessource. So, even if a script opted for the XML output, there is no clear dependency on using namespaced selectors here. Besides, all of those APIs mentioned also offer JSON output, which is much more optimised for use in JavaScript environments where cross site requests will be most common. So what other sorts of APIs do you have in mind which would greatly benefit from namespace support in selectors API? It would help if you could find some other APIs and illustrate with some real world sites that use them, where namespace-supporting APIs are utilised for good reasons on the client side. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? xml:id doesn't enable functionality that the id attribute on HTML, MathML or SVG elements doesn't enable, but xml:id comes with all sorts of complications. In addition to this complication, it has the complication that in an xml:id-enabled world, an element doesn't have a single attribute that has IDness. Instead, it has to have two (the natural choice flowing from XML specs) or the IDness of attributes has to depend on the presence of other attributes (the choice taken by SVG 1.2 Tiny). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [selectors-api] querySelector with namespace
On Thu, 26 Nov 2009 09:33:28 -0200, Henri Sivonen hsivo...@iki.fi wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: [...] Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Besides that, querySelector(#foo) and getElementById(foo) should work fine in xml:id implementations and both are much less cumbersome to type. -- Anne van Kesteren http://annevankesteren.nl/
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. What is the use case for xml:id on the web? Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. As for the issue of resolving namespace prefixes, the previous attempt at including them in the API proved to be a very difficult, time consuming and costly effort that failed to reveal substantial use cases, nor find a viable solution. As such, my current position is that there has been insufficient justification provided for spending such significant time and effort addressing this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
On 2009-11-26 12:33 PM, Henri Sivonen wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Please note my use of the phrase work around. Nowhere in my email did I suggest supporting xml:id on the Web. Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. xml:id doesn't enable functionality that the id attribute on HTML, MathML or SVG elements doesn't enable, but xml:id comes with all sorts of complications. In addition to this complication, it has the complication that in an xml:id-enabled world, an element doesn't have a single attribute that has IDness. Instead, it has to have two (the natural choice flowing from XML specs) or the IDness of attributes has to depend on the presence of other attributes (the choice taken by SVG 1.2 Tiny). I've been active in the Mozilla bug report filed for xml:id, so I'm aware of the issues. To my knowledge these have all been resolved satisfactorily, and the only reason the patch that was landed in Mozilla (net increase of 80 lines of code) didn't make it through to a release in 2007 was because of a performance regression, causing it to be removed. That issue is now also thought to be solved I believe. Having said all that, I'm not very keen on adding native support for xml:id. I'd rather just make 'id' in the null namespace special if at all possible. KISS, right? Anyways, back to my main point: script should be able to process arbitrary XML to present the results of that processing to the user using a belongs on the Web format, and better support for namespaces in querySelector would certainly help with that. Jonathan
Re: [selectors-api] querySelector with namespace
On 2009-11-26 1:16 PM, Lachlan Hunt wrote: Jonathan Watt wrote: Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. You're right, I'll email the CSS WG. As for the issue of resolving namespace prefixes, the previous attempt at including them in the API proved to be a very difficult, time consuming and costly effort that failed to reveal substantial use cases, nor find a viable solution. As such, my current position is that there has been insufficient justification provided for spending such significant time and effort addressing this issue. I don't think supporting prefixes in querySelector makes much sense. Jonathan
Re: [selectors-api] querySelector with namespace
On 2009-11-26 2:16 PM, Jonathan Watt wrote: On 2009-11-26 1:16 PM, Lachlan Hunt wrote: Jonathan Watt wrote: Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. You're right, I'll email the CSS WG. See http://lists.w3.org/Archives/Public/www-style/2009Nov/thread.html#msg321
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: On 2009-11-26 12:33 PM, Henri Sivonen wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Please note my use of the phrase work around. Nowhere in my email did I suggest supporting xml:id on the Web. Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. Why does it matter that the API can't select xml:id using a selector involving namespaces, especially given that xml:id is not used on the web, and even if it was, the ID selector would work fine? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
