Use Cases for Use Cases (was: [selectors-api] SVG WG Review of Selectors API)
Hi, Folks- It seems strange to have to explicitly say this about webapp technologies, but use cases obviously don't cover all the use cases. Web applications --the reason we're doing these specs at all-- were not within the scope of the introduction of HTML, CSS, Javascript, or any of the technologies that are now the foundations of webapps. People took those insufficient scraps and built amazing things with them, far beyond the intended use cases. This should be the sign of a well-designed technology: that it can be adapted to do something the original creator never envisioned. Yes, it is good to be methodical about covering all the bases. It is less good to limit the potential other uses. Lachlan Hunt wrote (on 1/28/09 6:40 PM): Giovanni Campagna wrote: This is was not a complete use case, it was just an example. Well, it's use cases that are needed, not just simple examples that are trivial to make up. Sorry, what precisely do you think use cases are? They are examples of what people will want to do with the technology. Stop artificially raising the bar for what you find acceptable rationales for inclusion. You don't like namespaces: we get that. But they exist, and we have to address them. You claim that there were too many technical challenges to including namespaces in this version; the SVG WG accepted that, and empathize with the notion of shipping an imperfect or incomplete spec, rather than the ideal spec, because of time constraints, implementation and shipping deadlines, and market pressures. That's reality. But please stop pretending that there are no use cases for namespace support, or that the use cases that are raised are insufficient, to be addressed by the Selectors API. That's not reality. People want to mix markup in documents, even markup we've never heard of or don't approve of. How we address that need is a technical issue, not an ideological or rhetorical one. Defining use cases is done to ensure that the known cases are covered by the technology, not to exclude options. Meeting use cases and requirements is necessary, but not sufficient. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Use cases for Selectors-API
27/12/2008 Jonas Sickings A few comments: * XPath works mostly fine on HTML already, firefox supports it. The only things that weren't defined by specs were a few things related to case sensitivity. According to the HTML5 specification, the HTML parser is not required to build an XML Information Set and this is the only normatively specified method to build and XPath data model (but not the only one allowed). If it works yet, I'm happy with that. * The fact that XPath can return non-nodeset values is totally unrelated to implementing a element.matchesSelector type API. What it means is that you can return things like numbers and strings, i.e. you can return the number of p children inside the body multiplied by the value in the 'hello' attribute of the first meta element. Actually I meant the use of boolean functions + the use of a context node. But yes, it has terrible perfomance issues. * Minor nit: It's called XPath, not XMLPath. No the complete name is XML Path Language (XPath) 2.0, according to the latest Rec. 2008/12/27 Boris Zbarsky bzbar...@mit.edu Giovanni Campagna wrote: - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) And Safari and IE8. But yes, the point that XPath is already supported as a selection mechanism is correct (though I can't recall what the status is across all browsers). In fact, various JS toolkits use it right now. sorry but I didn't know of Safari / IE8. Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML You forgot: - Selectors is designed to be fast to match, while XPath had no such design criterion; as a result it's very easy to write pathologically slow XPath queries, even by accident. For non-pathological cases, Selectors are still faster, whether because of spec design choices or because browsers already heavily optimize selector matching. That is an issue for browser vendors, not spec writers. And I think that if they optimized document.querySelectorAll(blockquote p) they can optimize document.evaluate(\\blockquote\p,...) For example, see http://ejohn.org/blog/queryselectorall-in-firefox-31/ for some performance data. The old API section is toolkits using whatever they had on hand before querySelector came along, including XPath. At least Prototype and Dojo do in fact use XPath if possible: those would be the first and third bar on the graph. The problem are toolkits, not XPath. The more javascript you use, the worse the performance, since JS is interpreted not compiled. If toolkits didn't rewrite complex CSS selectors in XPath syntax, performance would be similar. For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either While this may be true, the initial uptake for this feature is expected to be by toolkits, not authors directly. And you don't need to learn the Selectors Level 3 stuff to use this API, of course. You don't need selectors API for matching .my_class or object or even #my-id. Use getElement(s)ByClassName/TagName/Id (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) I don't see how any APIs here would make a difference to this last class of authors, unless you expect them to read tutorials or whatnot And in that case, you're back to people not learning from the specs. I meant that any new API is a problem beacuse authors don't learn quickly. (and DOM3XPath is not new, selectors API instead is) For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. That seems like it would be better suited to the public-html mailing list, no? Jonas says that this problem is also resolved. (and public-html is not actually public, because of patents) I'm very curious about what your answer will look like (it seems to me that I discovered hot water) No, more like repeated the same old arguments yet again. Same old questions = same old answers? I don't think these are enough Giovanni
Re: Use cases for Selectors-API
On Sat, 27 Dec 2008 16:20:57 +0100, Giovanni Campagna scampa.giova...@gmail.com wrote: 27/12/2008 Jonas Sickings * Minor nit: It's called XPath, not XMLPath. No the complete name is XML Path Language (XPath) 2.0, according to the latest Rec. XPath is a commonly used abbreviation, XMLPath is not. Also note that Web browsers do not implement XPath 2.0. That is an issue for browser vendors, not spec writers. And I think that if they optimized document.querySelectorAll(blockquote p) they can optimize document.evaluate(\\blockquote\p,...) Except that optimizing the former gives the browser greater benefits (faster CSS computations) than spending time on optimizing the latter. While this may be true, the initial uptake for this feature is expected to be by toolkits, not authors directly. And you don't need to learn the Selectors Level 3 stuff to use this API, of course. You don't need selectors API for matching .my_class or object or even #my-id. Use getElement(s)ByClassName/TagName/Id But for e.g. div h2 you do. I meant that any new API is a problem beacuse authors don't learn quickly. (and DOM3XPath is not new, selectors API instead is) But most Web authors know Selectors (from CSS), but hardly know XPath. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Use cases for Selectors-API
So I consider the main reason for the Selector API is that many more developers are familiar with selectors than are familiar with XPath. I base this on the fact that many more pages use CSS stylesheets than use XPath, by several orders of magnitude (probably more than 3). It is also demonstrated by the fact that many popular JS toolkits supply an API to let you query for elements using a selector. So while XPath is able to fetch the same information as the new Selector API it requires one of two things to happen: 1. Either the author needs to learn XPath in addition to the Selector syntax. 2. A library needs to translate the CSS selector into an XPath expression. Today 2 seems to be what happens most of the time. As Boris pointed out, this has been shown to have some rather unfortunate performance penalties, see [1]. There is also another argument other than 'people already know selectors' that I have heard. It is quite possible that they want to use the *same* selectors in a stylesheet as in the JS code. This advantage would hold true even for authors that know both XPath as well as selectors. However, I have not heard many examples of when this would happen so I wouldn't rely on this argument too heavily. I don't understand your argument that you have to learn the latest version of the selectors language. You can just stick with whatever subset you know, even if that isn't even all of level 1. Yes, in some cases you can just stick with DOM-Core, but for those cases nothing of what we're discussing here matters at all, you shouldn't use XPath for those either. So I'm not sure why you bring that up? On the flip side, I don't buy the performance argument that selectors are faster than XPath, when the raw API is used directly. While selectors were designed with higher constraints regarding performance, this is largely related to performance in case of modifications to the document. I.e. a CSS implementation needs to track dependencies and figure out which selectors to reevaluate when a given change happens to the document. Such requirements does not apply here. You could equally much claim that selectors were designed with does this node match that selector in mind, whereas XPath was designed with give all the nodes that match this expression in mind. The latter is what we are doing here. The performance benefit that exists in [1] is mostly likely due to not having to translate the selector into XPath. There is also the fact that the somewhat more powerful syntax of XPath might allow more things to be done in XPath and less require JS filtering after the XPath/selector has been run. Then there is the fact that if someone does document.querySelector(html body p[foo] span[bar]) most (all?) current implementations walk the whole DOM trying to match each node, whereas an XPath implementation will only walk the necessary nodes for an expression like html/body/p...@foo]/sp...@bar]. This will likely become more important once :scope (or whatever it'll be called) starts to get used as we'll have selectors like :scope div.foo On the other hand, selectors have fast class matching, which XPath 1 doesn't have. Not sure if XPath 2 does, but I haven't heard anyone expressing interest in implementing that. [1] http://ejohn.org/blog/queryselectorall-in-firefox-31/ / Jonas
Re: Use cases for Selectors-API
Giovanni Campagna wrote: - Selectors is designed to be fast to match, while XPath had no such design criterion; as a result it's very easy to write pathologically slow XPath queries, even by accident. For non-pathological cases, Selectors are still faster, whether because of spec design choices or because browsers already heavily optimize selector matching. That is an issue for browser vendors, not spec writers. And that attitude is exactly why there are XPath queries that just can't be fast. And I think that if they optimized document.querySelectorAll(blockquote p) they can optimize document.evaluate(\\blockquote\p,...) Sure, but as soon as you forget that leading \\ you lose, no? The problem are toolkits, not XPath. The more javascript you use, the worse the performance, since JS is interpreted not compiled. If toolkits didn't rewrite complex CSS selectors in XPath syntax, performance would be similar. I can guarantee you that CSS selector performance in Gecko is faster than XPath and is likely to stay that way indefinitely. You don't need selectors API for matching .my_class or object or even #my-id. Use getElement(s)ByClassName/TagName/Id No, but as soon as you want #mymaintext .my_class you do. And thi is hardly unknown CSS3 stuff. I meant that any new API is a problem beacuse authors don't learn quickly. (and DOM3XPath is not new, selectors API instead is) Authors are already using API like this through the toolkits; they'll immediately see speedups in their code and won't have much of a jump to use the API directly. Same old questions = same old answers? Yes. They seem to have been considered sufficient the previous times around. I don't think these are enough You're always welcome to raise a formal objection, of course. -Boris
Use cases for Selectors-API
As for the subject, I was wondering what are the use cases for Selectors API. Yes, author desperately need a way to get element that match some constraint inside a document (ie all tables or all p span.urgent elements). But they already have a language to implemented this: XML Path Language + DOM3 XPath. Advantages of XMLPath vs Selectors: - you can use namespaces (you can in selectors too, but not in selectors api) - you can return non-node values (ie. the element.matchesSelector equivalent), either ordered or unordered (possibly faster) node iterators - you can extend syntax by adding new functions in different namespace (this is required to support UI pseudo-classes, and actually there are no facilities to do this) - once XMLPath model is implemented, also XQuery is easily implemented and XQuery features are incredible: what about reordering a table without using HTML5 datalist or java applet? or finding a row in that table based on user input, without using ctrl+f? - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either and anyway they have to learn the Selectors-API (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. I'm very curious about what your answer will look like (it seems to me that I discovered hot water) Giovanni
Re: Use cases for Selectors-API
On Fri, Dec 26, 2008 at 10:26 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: As for the subject, I was wondering what are the use cases for Selectors API. Yes, author desperately need a way to get element that match some constraint inside a document (ie all tables or all p span.urgent elements). But they already have a language to implemented this: XML Path Language + DOM3 XPath. Advantages of XMLPath vs Selectors: - you can use namespaces (you can in selectors too, but not in selectors api) - you can return non-node values (ie. the element.matchesSelector equivalent), either ordered or unordered (possibly faster) node iterators - you can extend syntax by adding new functions in different namespace (this is required to support UI pseudo-classes, and actually there are no facilities to do this) - once XMLPath model is implemented, also XQuery is easily implemented and XQuery features are incredible: what about reordering a table without using HTML5 datalist or java applet? or finding a row in that table based on user input, without using ctrl+f? - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either and anyway they have to learn the Selectors-API (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. A few comments: * XPath works mostly fine on HTML already, firefox supports it. The only things that weren't defined by specs were a few things related to case sensitivity. * The fact that XPath can return non-nodeset values is totally unrelated to implementing a element.matchesSelector type API. What it means is that you can return things like numbers and strings, i.e. you can return the number of p children inside the body multiplied by the value in the 'hello' attribute of the first meta element. * Related, XPath *can't* in fact be used to implement element.matchesSelector. At least not without incredible performance costs. The problem is that the full XPath language is actually too powerful. Something like myElement.matchesXPath(id(node())) would require walking the entire DOM and checking if the XPath value of the node is the same as the ID of myElement. This can get arbitrarily complicated such as myElement.matchesXPath(id(concat(., @*[3], ..))) which would essentially require evaluating the full expression with each node (including each namespace and attribute node) in the document as the context node. When XPath was developed, which happened alongside with XSLT, this exact problem was actually run into. The solution was that XSLT defines a similar, but distinct, language called 'patterns'[1] used in situations when you need to match a node against an expression. (In firefox the code for patterns is largely separate from the code for XPath) * Minor nit: It's called XPath, not XMLPath. [1] http://www.w3.org/TR/xslt#patterns / Jonas
Re: Use cases for Selectors-API
Giovanni Campagna wrote: - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) And Safari and IE8. But yes, the point that XPath is already supported as a selection mechanism is correct (though I can't recall what the status is across all browsers). In fact, various JS toolkits use it right now. Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML You forgot: - Selectors is designed to be fast to match, while XPath had no such design criterion; as a result it's very easy to write pathologically slow XPath queries, even by accident. For non-pathological cases, Selectors are still faster, whether because of spec design choices or because browsers already heavily optimize selector matching. For example, see http://ejohn.org/blog/queryselectorall-in-firefox-31/ for some performance data. The old API section is toolkits using whatever they had on hand before querySelector came along, including XPath. At least Prototype and Dojo do in fact use XPath if possible: those would be the first and third bar on the graph. For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either While this may be true, the initial uptake for this feature is expected to be by toolkits, not authors directly. And you don't need to learn the Selectors Level 3 stuff to use this API, of course. (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) I don't see how any APIs here would make a difference to this last class of authors, unless you expect them to read tutorials or whatnot And in that case, you're back to people not learning from the specs. For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. That seems like it would be better suited to the public-html mailing list, no? I'm very curious about what your answer will look like (it seems to me that I discovered hot water) No, more like repeated the same old arguments yet again. -Boris
