views:

114

answers:

4

JavaScript lets you add arbitrary properties and methods to any object, including DOM nodes. Assuming the property was well namespaced (something like _myLib_propertyName) so that it would be unlikely to create a conflict, are there any good reasons not to stash data in DOM nodes?

Are there any good use cases for doing so?

I imagine doing this frequently could contribute to a sloppy coding style or code that is confusing or counter-intuitive, but it seems like there would also be times when tucking "custom" properties into DOM nodes would be an effective and expedient technique.

+1  A: 

If you look at HTML 5 there is the data attribute for fields that will allow you to store information for the field.

darren102
+2  A: 

I think more than anything, the best reason not to store data in the DOM is because the DOM is meant to represent content structure and styling for an HTML page. While you could surely add data to the nodes in a well-namespaced manner as to avoid conflicts, you're introducing data state into the visual representation.

I'm trying to find an example for or against storing data in the DOM, and scratching my head to find a convincing case. In the past, I've found that the separation of the data state from the visual state has saved headache during re-designs of sites I've worked on.

Robert Hui
There is a post here on extending the DOM: http://perfectionkills.com/whats-wrong-with-extending-the-dom/
huntaub
Thank you for reminding me of what I should already have known! Separate style, structure, and behavior!
jasongetsdown
@huntaub excellent link, even if the writer's grammar is a little odd. I think the section that answers my question best would be "Wrappers to the Rescue." Don't extend DOM objects, wrap them and add your custom properties to the wrapper. Extending DOM objects is a bigger cross-browser cluster-f*** than I realized.
jasongetsdown
A: 

Don't be surprised to run into trouble with IE 6 & 7. They are very inconsistent with setAttribute vs set as a property.

And if you're not careful you could set circular references and give yourself a memory leak.

http://www.ibm.com/developerworks/web/library/wa-memleak/

I always set node properties as a last resort, and when I do I'm extra careful with my code and test more heavily than usual.

mwilcox
+3  A: 

No, it is a very bad idea to store your own properties on DOM nodes.

  • DOM nodes are host objects and host objects can do what they like. Specifically, there is no requirement in the ECMAScript spec for host objects to allow this kind of extension, so browsers are not obliged to allow it. In particular, new browsers may choose not to, and existing code relying on it will break.
  • Not all host objects in existing browsers allow it. For example, text nodes and all ActiveX objects (such as XMLHttpRequest and XMLDOM objects, used for parsing XML) in IE do not, and failure behaviour varies from throwing errors to silent failure.
  • In IE, the ability to add properties can be switched off for a whole document, including all nodes within the document, with the line document.expando = false;. Thus if any of the code in your page includes this line, all code relying on adding properties to DOM nodes will fail.
Tim Down