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).
How does using userData differ from using expandos? Why would one want to use use it rather than an expando?
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.).
If the problem is collisions we should do something much simpler than UserData imo. (Note that UserData is tentatively removed from Web DOM Core.)
(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?
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.
Mass moving XML DOM bugs to the "DOM" Component.
This feature is no longer standardized. The alternative is using WeakMap.