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.