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

Re: Change to Attr interface in light of XPath

From: Justin Summerlin <justin@inkling.com>
Date: Tue, 18 Feb 2014 12:02:17 -0800
Message-ID: <CAA2YHm44yb4gaJ-tHJFHJ-AGdEWiocpVa9zTNRanAmF6knKfwg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, DOM public list <www-dom@w3.org>
I do agree that ownerElement should be put back.

But by not fully inheriting from Node, we lose symmetry with other types of
objects returned from XPath queries; we lose nodeType for example. If I get
a result object and nodeType tells me nothing, I need to look at the
prototype of the object or look at ownerElement, in this case, and see if
that object is in the attribute list just to know what kind of object I'm
working with.

On Tue, Feb 18, 2014 at 9:20 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Feb 18, 2014 at 9:15 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 2/17/14 4:38 PM, Justin Summerlin wrote:
> >>
> >> This is somewhat problematic since accessing
> >> the parent element is needed for our use.
> >
> >
> > Exposing a .parentNode on Attr (returning the element it came from) does
> not
> > require all the other Node baggage (child nodes, etc, etc).
> >
> > If there are use cases for a .parentNode, as here, exposing it seems
> fine.
> attributenode.parentNode has always returned null. In all versions of
> the spec and in all implementations. What you want is
> attributenode.ownerElement. I'm surprised that it's been removed from
> the new spec. I agree that it needs to be put back.
> / Jonas
Received on Tuesday, 18 February 2014 20:05:03 UTC

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