Re: Change to Attr interface in light of XPath

On Tue, Mar 18, 2014 at 10:33 AM, Anne van Kesteren <[email protected]> wrote:
> On Tue, Feb 18, 2014 at 5:20 PM, Jonas Sicking <[email protected]> wrote:
>> 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.
>
> Why?
>
> It returns undefined in all implementations. (I didn't test this and
> just went by your word initially, reverting that now.)

I guess that at some point Gecko and other browsers removed this
property since it was removed from the spec.

However that still leaves us without a plan to deprecate Attr objects
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=25016), but with those
Attr objects being pretty broken since there's no way to get back to
their "parent".

I guess since the web didn't break when we removed Attr.ownerElement
we won't break that many people by leaving it out. But it does mean
that we have created a pretty awkward API where you can get to Attr
objects, but you can't get back.

The only real thing that I can think of that we've broken is the DOM
XPath API, which isn't much in favor any more, but I have no idea how
much usage it has (more than XSLT almost certainly).

On the other hand, it seems somewhat silly to remove ownerElement
since the implementation needs to hold a reference from the Attr
object to the Element anyway in order to implement the .value setter.

/ Jonas