Re: Change to Attr interface in light of XPath

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
>
>