Browser-compat-data: Data for localName/namespaceURI/prefix attributes on Attr/Element/Node is inconsistent/confusing

[foolip]

The brief history of what happened here is:

• Since ancient browser past, localName, namespaceURI, and prefix were on the Node interface, and the Attr and Element interfaces inherited from Node. The 3 attributes would only return something non-null on Attr and Element
• Between 2010–2016 there was an effort called "AttrExodus" in https://dom.spec.whatwg.org/ where we tried to make Attr not inherit from Node, because it's a silly API.
• It wasn't completed, but as a side effect localName, namespaceURI, and prefix were moved from Node to Attr + Element. This change was implemented even though the final part of the "AttrExodus" plan was not.

As a result, the three attributes moved from Node to Attr + Element at some point, which is easy to test for.

The change was believed to have minimal impact on web developers because it only changes where on the prototype chain the attributes are, and in some cases (like document.localName) would change the value from null to undefined. The change worked out, so this seems to have been true.

Unfortunately, the change still makes MDN and BCD more involved than ideal and I'm filing this issue to sort it out. Problems:

• BCD for Attr and Element document the transition in some cases, and in others not. For Internet Explorer it says no support for Attr attributes, but actually they can be used, as they're inherited from Node.
  
  
  
  • BCD for Node still has the attributes, and the MDN page has fairly prominent warnings about them. Again, the change should scarcely matter.
  
  

I'm filing an issue about this because fixing it will require coordinating changes on MDN pages with BCD.

This is a specific instance of a more general problem: How to represent changes/moves on the prototype chain

[foolip]

https://github.com/mdn/browser-compat-data/pull/6546 should be an uncontroversial part of this cleanup. How to fix the 3 attributes might run into more room for personal preference I think.

[foolip]

My preference for how to resolve the rest of this is:

• Remove the entries on Node in BCD and on MDN
• Mark the Attr/Element variants as supported since ancient times, and don't mention that they've moved down from Node on the prototype chain

In other words, document it as if they've always been on Attr and Element, because this is effectively true: they've always worked on instances of Attr and Element, and for other Node types they returned null when originally "supported".

@ddbeck how should we go about deciding on this case? Should I just send a PR, or would this be setting a precedent, so that a decision on https://github.com/mdn/browser-compat-data/issues/3463 is needed?

[ddbeck]

Yeah, this is a weird situation. In the Before Times, I'd have a team of writers to talk to about stuff that touches the way content is organized on the wiki, which would probably lead us in this. Now, I don't really know what the process is—or if there is or should be a process. I'm going to check in on this and figure out next steps soon. I'll try to give you some sort of answer within one week (definitely @-me if I have not given a satisfactory response by then).

[foolip]

Thanks @ddbeck! There's no urgency on this, it's just one of the first things in https://github.com/mdn/browser-compat-data/pull/6526 so I will keep being reminded of it :)

[sideshowbarker]

My preference for how to resolve the rest of this is:

• Remove the entries on Node in BCD and on MDN
• Mark the Attr/Element variants as supported since ancient times, and don't mention that they've moved down from Node on the prototype chain

In other words, document it as if they've always been on Attr and Element, because this is effectively true: they've always worked on instances of Attr and Element, and for other Node types they returned null when originally "supported".

+1 to that. It sounds to me like the most-reasonable way to handle it all at this point.

[Elchi3]

My preference for how to resolve the rest of this is:

* Remove the entries on Node in BCD and on MDN

* Mark the Attr/Element variants as supported since ancient times, and don't mention that they've moved down from Node on the prototype chain

In other words, document it as if they've always been on Attr and Element, because this is effectively true: they've always worked on instances of Attr and Element, and for other Node types they returned null when originally "supported".

Sounds good to me, too. The practical implications to web authors here seem very minor, so documenting what happened in the spec world seems to just complicate docs and compat data for no real reason.