Bug 39699 – Implement DOM Level 3 Node::getUserData/setUserData

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[kangax]

DOM Level 3 is currently draft, but `Node::getUserData` (http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData )/`Node::setUserData` (http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-setUserData ) are already implemented in Mozilla and are a convenient way to store user data for node (instead of assigning expandos).

[Sam Weinig]

How does using userData differ from using expandos?  Why would one want to use use it rather than an expando?

[kangax]

The problem with expandos is collisions with members of any interfaces implemented by a node in question. How can you have a data under a key of "nodeName", "appendChild", etc. In implementations that make DOM objects inherit from Object.prototype or Function.prototype (such as webkit) there's additional set of candidates for collisions (toString, constructor, call, etc.).

[Anne van Kesteren]

If the problem is collisions we should do something much simpler than UserData imo. (Note that UserData is tentatively removed from Web DOM Core.)

[kangax]

(In reply to comment #3)
> If the problem is collisions we should do something much simpler than UserData imo. (Note that UserData is tentatively removed from Web DOM Core.)

Ok. But simpler how? I can imagine something like `Node::userData` (shorter name + no function call) where `userData` would need to be explicitly specified to have [[Prototype]] of null.

Or did you mean something else?

[John-David Dalton]

I know there are also issues with expando's and cloneNode() in IE (IE copies non-object value expandos to the clone, and also issues with some Java Applets barfing when devs attempt to set expando's on them.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.

[Anne van Kesteren]

This feature is no longer standardized. The alternative is using WeakMap.