1221255 - Make Attr.nodeValue and Attr.textContent directly alias for Attr.value

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[Arkadiusz Michalski (Spirit)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Per DOM spec Attr.nodeValue and Attr.textContent should be defined directly in Attr interface and be an alias for  Attr.value:
https://dom.spec.whatwg.org/#dom-attr-value
They were added because usage frome Chrome status is hight:
https://www.chromestatus.com/metrics/feature/timeline/popularity/348
https://www.chromestatus.com/metrics/feature/timeline/popularity/349

I see that Chrome 46 (stable) make this change so probably Firefox can safely follow with them.

Btw, Attr.value doesn't have any special requirements for null value, so Attr.nodeValue and Attr.textContent (as alias) should behave similarly (oposite to Node.nodeValue and Node.textContet). Chrome in this case has probably small bug.

Small testcase:
<script>

	var el = document.createElement("div");
	el.id = "test";
	var firstAttr = el.attributes[0];

	console.log(Attr.prototype.hasOwnProperty("textContent")); // should be true
	console.log(firstAttr.__proto__.hasOwnProperty("textContent")); // should be true
	console.log(firstAttr.__proto__);

	firstAttr.textContent = null;
	console.log(firstAttr.textContent); // should be "null"

</script>

Comment 1

[Arkadiusz Michalski (Spirit)]

Now I see that some times ago Attr.nodeValue and Attr.textContent got [TreatNullAs=EmptyString], so Chrome is correct here, sorry for the confusion.
https://github.com/whatwg/dom/pull/36