https://github.com/whatwg/dom/commit/db19f1c8de8fb78e2ef1218b45a7c967b6a5822d

I can't find why this is needed in the linked discussion, just the observation that there exists other baggage with Attr. Just today I submitted a review to count how often the associated element is actually needed: https://codereview.chromium.org/203313002/

Is there any data to show that it is needed for Web compat, so that I can save the effort?

No please go ahead. 

It seemed in the discussion that you needed Attr.prototype.ownerElement if you have an API like XPath (granted, not the best use case). Jonas also seemed in favor of it. Maybe I should poke a bit more.

Oh, seems like Attr.ownerElement is a new invention? Blink doesn't have any IDL attribute by that name anywhere, so it can't be needed for Web compat. Adding new API surface to Attr seems like a terrible idea, so reopening this bug.

Per http://www.w3.org/TR/DOM-Level-3-Core/core.html#Attr-ownerElement it has been around for a while. Granted, I did not test it, just assumed it was around.

In a bit of ad-hoc testing I'm not able to find an attribute on Attr which leads back to the Element it came from, at least in Blink parentNode and parentElement are just null...

Agreed. (It seems Safari implements ownerElement, but they also implement other crap, such as isId...)

In Chrome stable (33.0.1750.117) Attr.prototype.ownerElement points back to the element. The removal is set to land in 34 and the change cites DOM4. The same is true of Firefox's deprecation and the corresponding change on MDN indicating the attribute is removed in DOM4.

The IDL for Blink was modified in January: http://src.chromium.org/viewvc/blink?view=revision&revision=164820.

(In reply to Philip Jägenstedt from comment #2)
> https://codereview.chromium.org/203313002/

If attribute's value setter is really the only thing that requires the reference to its parent element, maybe we should look into making it readonly?

I wonder how often attributes are updated via their nodes. I suspect setAttribute would be the vast majority of use.

However, even though XPath might be a poor justification, browser support for it may likely still require the element reference:

http://jsfiddle.net/WQLP7/

This is probably tenuous, but I don't know as much about the XPath specs to know if this is required to work.

Oh, I didn't realize ownerElement was just recently removed from Blink, in that case it doesn't follow that it's not needed for Web compat.

(In reply to Anne from comment #9)
> (In reply to Philip Jägenstedt from comment #2)
> > https://codereview.chromium.org/203313002/
> 
> If attribute's value setter is really the only thing that requires the
> reference to its parent element, maybe we should look into making it
> readonly?

The getter can need it to, since the Element's attribute be changed using setAttribute() after the Attr object is created. (This is assuming an Attr implementation that's just used for DOM bindings, i.e. that it isn't the same object that's used to actually store attributes internally.)

(In reply to Philip Jägenstedt from comment #12)
> (In reply to Anne from comment #9)
> > (In reply to Philip Jägenstedt from comment #2)
> > > https://codereview.chromium.org/203313002/
> > 
> > If attribute's value setter is really the only thing that requires the
> > reference to its parent element, maybe we should look into making it
> > readonly?
> 
> The getter can need it to, since the Element's attribute be changed using
> setAttribute() after the Attr object is created. (This is assuming an Attr
> implementation that's just used for DOM bindings, i.e. that it isn't the
> same object that's used to actually store attributes internally.)

That being said, if Attr.value could be successfully be made readonly, one could probably get rid of the Element reference in the getter by just making the Element.setAttribute() and friends update the Attr objects in its children array. That seems like sensible layering to me, at least.

I mean the attributes array, obviously.

I added two use counters to Blink to answer the readonly question:

AttrGetValue: http://www.chromestatus.com/metrics/feature/timeline/popularity/298
AttrSetValue: http://www.chromestatus.com/metrics/feature/timeline/popularity/299

These don't distinguish whether or not the Attr object is attached to an Element at the time, would that be in any way useful to know?

No, I think if people expect setting to work it should always work. We shouldn't make it depend on whether or not they are attached to elements, that would be a pretty awkward API.

Hi. I had opened this issue in another bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25021

which Robin just closed and pointed me at this one.

My comments can in general are tied in with the comments above: I use XPath, in a browser, and reach attribute nodes. I then need access to the ownerElements of these nodes.

But to me, this whole matter is a symptom of a larger problem. Robin quoted this in his closing of the other bug:

"Note that while it is supported in Gecko and WebKit, it has recently been removed from Blink which ought to indicate that it is not needed. If you have data indicating the contrary, it would be a great idea to share it."

I've noticed there have been other justifications for removal of features because of "data" that Google and others are collecting regarding usage. That would be all fine and well if Google could reach all of the websites affected - but they can't and never will. That's because there are many, many websites behind corporate firewalls that Google and other indexing engines will never reach. These browser users (i.e. customers) are deploying internal back-office Web applications that use W3C-approved APIs - APIs that have gone through the (long and tortuous) standardization process and have been in place for years and years. And these applications built with those APIs will now be in use for years and years to come.

Now, there are some APIs that are being removed that were not part of a W3C approved API - those I don't have a problem with. They were some sort of vendor extension, etc. and could't really be counted on to be 'future proofed' as such. 'ownerElement', however, has been around a long time - and has a real use even in a world where Attributes are no longer Nodes.

I'm not sure where this desire to be anything other than additive to existing W3C-approved APIs comes from, but it is highly concerning, however, to think there are codebases in use today that *will* break because folks don't really have the entire 'usage data' picture, even if they think they do.

Sorry if this got soapboxy.

Cheers,

- Bill

It looks like the ownerElement removal is being reverted in Firefox as well as Blink: https://bugzilla.mozilla.org/show_bug.cgi?id=957431#c44.

(In reply to Justin Summerlin from comment #18)
> It looks like the ownerElement removal is being reverted in Firefox as well
> as Blink: https://bugzilla.mozilla.org/show_bug.cgi?id=957431#c44.

Yes, I reverted it in Gecko a few weeks ago.

It's back. We could not remove the ability to set .value. :-(

*** This bug has been marked as a duplicate of bug 26596 ***