Using the selector API with XML documents

Question

Short question: is the selectors API sensible for processing XML documents?

Longer question with the "why I'm asking"...
I'm in the progress of making some old code that makes use of client-side generated XML and XPath into something cross-browser that's happy on later versions of IE (10+) as well as down to IE7 (as well as Chrome, Firefox, etc...)

Now there's various questions around XPath support in IE and the fact it appears to be no longer cared for (no evaluate(), no SelectNodes()). Allegedly some classes have been whitelisted, but some testing seems to hint this is unreliable when ActiveX filtering is enabled in IE10.

I've played with wicked-good-xpath, but I've bumped into issues with some forms of XPath. In addition if IE is never going to have XPath support again, I'd rather not be permenantly reliant on an external library, and find the next "best" thing to use instead.

It's been pointed out that the selector API is now the recommended choice instead. The problem I have with this though is that it primarily appears to be a HTML selection API (mostly as it grew out of CSS and as such it has special cases for class and ID attributes - there maybe other HTML-isms I've not yet seen).

Thus is the selectors API sensible for processing XML documents? Given the lack of support in IE, the answer is probably "yes", but I can't see anything authoritative that gives a definite recommendation (or anti-recommendation).

Answer 1

It certainly is. Although CSS was indeed designed to be a companion to HTML, it was also designed to be document language agnostic, with HTML-isms defined separately from the general rules (while still being compatible), and so is the Selectors standard derived from the CSS selector syntax.

The Selectors standard, on which the Selectors API is based, begins thusly:

Selectors are patterns that match against elements in a tree, and as such form one of several technologies that can be used to select nodes in an XML document. Selectors have been optimized for use with HTML and XML, and are designed to be usable in performance-critical code.

Implementations can construct DOM trees out of HTML or XML using an appropriate parser, which can then be queried using selectors. You shouldn't have any trouble matching XML elements using selectors.

Note that while HTML and XML do in fact share ID and class semantics (you can define ID and IDREF attributes in an XSD for example), you can only match them using ID and class selectors if the Selectors API implementation knows how that particular flavor of XML defines those semantics. Since the implementation you're using is a browser, chances are the only XML flavors it understands are widely-adopted Web standards like SVG and MathML, and not for instance your in-house XML flavor. You still have your basic type selectors, attribute selectors, structural pseudo-classes and combinators at your disposal though, which should be more than enough for your needs.

Most of the limitations you'll end up running into will probably lie in the selector syntax itself, although some of these limitations are being rectified in Selectors level 4 and Selectors API level 2, with the subject indicator, :matches(), extended :not(), :nth-match(), :nth-last-match(), and :scope, among others.