W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2014

Re: Change to Attr interface in light of XPath

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>
Message-ID: <g3n9g9doh2bgh3hg10ic8g09go41k7r49o@4ax.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:22 UTC