[feature-request]Object.prototype.toString.call(<Element>) should return "[object Element]" to match browser behavior
Problem Description: The xmldom library's Element objects return a different string than native browser Element objects when Object.prototype.toString.call() is used. Specifically, browsers return "[object Element]" for DOM elements, while xmldom does not. This discrepancy breaks type detection in code relying on this behavior.
Proposed Solution: Add the following toString method to the Element.prototype:
Element.prototype.toString = function() {
return "[object Element]";
};
Thank you for filing the feature request. I need to check what the current behavior is, but I assume it serializes the element representation to its XML string? If that is the case, implementing this feature would be a breaking change, since users of xmldom might also rely on the current behavior.
I also can not find any mention of toString in the DOM API specification
https://dom.spec.whatwg.org/#element
So for considering this I would prefer to have more information about how widespread the usage is, compared to e.g. comparing the prototype directly or its name instead of calling toString.
So if you (any reader of this message) have more context/usage references for the requested behavior, please add it here.
Currently, calling Object.prototype.toString.call() returns [object Object]. This is indeed not part of the DOM API specification. However, since xmldom is a ponyfill, I hope its behavior can align with that of browsers.
Not only Element. In browsers, when calling Object.prototype.toString.call() on different types of DOM nodes, the return values are more specific. For example:
- For a <div/> element, it returns [object HTMLDivElement].
- For a text node, it returns [object Text].
- For a comment node, it returns [object Comment].
This behavior allows developers to precisely identify the type of a DOM node. However, in xmldom, calling Object.prototype.toString.call() on any node currently returns [object Object], which is less specific and inconsistent with browser behavior.
Implementing this would indeed be a significant amount of work, as it requires handling various node types. I'm not sure if others have the same needs as I do.
For now, the instanceof keyword can be used as a workaround, and it works correctly.
Thanks for your time and consideration!
xmldom in its current state is an inconplete ponyfill, indicated by the version number 0.*
And there is currently no differentiation of different element types at all. So the maximum possible would be to implement a generic return value based on the prototype, as in your original request.
I wonder what keeps you from comparing the prototype of the instance against the expected prototype of the node and e.g. checking the tag name when looking for a div? That feels like the more straight forward and reliable method for this. And I'm wondering where the recommendation to use toString for that comes from.
Some legacy code relies on Object.prototype.toString.call() for type checking. I think it might have been initially used to replace the less accurate typeof operator.I also think using instanceof is better.
Thank you for your time and for considering this request!