- From: Steve Schafer <steve@fenestra.com>
- Date: Wed, 19 Feb 2014 11:34:24 -0500
- To: Robin Berjon <robin@w3.org>
- Cc: Justin Summerlin <justin@inkling.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, DOM public list <www-dom@w3.org>
On Wed, 19 Feb 2014 12:18:03 +0100, you wrote: >Inheriting fully from Node is pretty heavy-handed, and for many things >feels quite unnatural. > >Do you have an implementation of XPath in JS? Maybe the simplest thing >would be to show what information you need on Attr for it to work; it's >likely to cover general-purpose requirements pretty well. There seem to be two separate things being intertwined here: 1) support of XPath, and 2) availability of navigational methods on attribute objects vs. those on "normal" nodes. As for (1), all that is required is that both "normal" nodes and attributes support XPath navigation. That is, given the de facto standard JavaScript XPath syntax: document.evaluate(<expression>, <contextNode>, ...) the implementation has to be willing to accept an attribute object as the <contextNode> argument. If you do something silly like trying to get the descendants of an attribute, or the attributes of a text node, you just get an empty result set. No harm, no foul. As for (2), that doesn't have anything to do with XPath per se. You may have gotten to a node or attribute via XPath, but as soon as you start calling DOM object navigational methods, XPath is out of the picture. Finally, getting back to the OPs original issue, if you want to stick to pure XPath, a query expression of ".." will return an attribute's owner element. -Steve Schafer
Received on Wednesday, 19 February 2014 16:34:41 UTC