xmldom icon indicating copy to clipboard operation
xmldom copied to clipboard

[feature-request]Object.prototype.toString.call(<Element>) should return "[object Element]" to match browser behavior

Open jinyu2022 opened this issue 11 months ago • 5 comments

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]";
};

jinyu2022 avatar Jan 25 '25 06:01 jinyu2022

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.

karfau avatar Jan 25 '25 09:01 karfau

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.

jinyu2022 avatar Jan 25 '25 10:01 jinyu2022

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!

jinyu2022 avatar Jan 25 '25 10:01 jinyu2022

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.

karfau avatar Jan 25 '25 10:01 karfau

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!

jinyu2022 avatar Jan 25 '25 11:01 jinyu2022