Re: Use cases for Selectors-API

On Fri, Dec 26, 2008 at 10:26 PM, Giovanni Campagna
<scampa.giovanni@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

Received on Friday, 26 December 2008 23:40:16 UTC