23

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.

zifot
  • 2,688
  • 20
  • 21
jasongetsdown
  • 1,295
  • 1
  • 17
  • 22
  • 4
    At least Juriy Zaytsev [(kangax)](http://stackoverflow.com/users/130652/kangax) thinks you [shouldn't do this](http://perfectionkills.com/whats-wrong-with-extending-the-dom/). – Marcel Korpel Jun 22 '10 at 17:03
  • Note from the future: ES 5.1 from June 2011 has [`Object.seal()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/seal) which prevents you from adding properties to an object. – Arc Jun 20 '16 at 14:15

5 Answers5

19

No, it is usually a 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
  • 318,141
  • 75
  • 454
  • 536
  • 1
    For the number 1) Browser developers are not desirous of breaking thinks. Especially in such a competitive market. I do not think they will break host objects extensions. Number 2 and 3 is no longer a problem because IE is obsolete as of 2020. – Zortext Feb 22 '20 at 14:33
  • 1
    @Zortext: I agree that things have changed in 10 years: IE < 11 have gone and I think (although I can't now find it) that current standards explicitly allow adding custom properties, so it's safer than it was. I would still recommend against it though. I wouldn't say IE is totally obsolete: IE 11 is hanging around and many of us still have to deal with it. – Tim Down Feb 25 '20 at 10:05
8

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
  • 744
  • 4
  • 8
  • 3
    There is a post here on extending the DOM: http://perfectionkills.com/whats-wrong-with-extending-the-dom/ – jhleath Jun 22 '10 at 17:35
  • Thank you for reminding me of what I should already have known! Separate style, structure, and behavior! – jasongetsdown Jun 22 '10 at 18:42
  • @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 Jun 22 '10 at 18:57
  • The DOM does not represent styling, it represents *meaning*. So in some cases it may be appropriate to do this (not that I recommend it). – rvighne Jul 25 '16 at 15:17
  • 1
    Just a note: not all DOM nodes and properties are for structure and styling e.g. `video.autoPlay = true`, `video.volume = 0` off the top of my head. –  Jun 19 '17 at 14:23
3

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,830
  • 1
  • 22
  • 24
  • 4
    Albeit, this does not include all JavaScript data types. When adding an attribute on to the dom (rather than a property), the data stored is a string. When it is retrieved it is converted into either a string or an integer based on its value. This is not a reliable method of starting Objects or Arrays on to a DOM element. – Swivel Jun 06 '13 at 22:23
0

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
  • 4,065
  • 23
  • 20
0

For what it's worth, the D3.js library makes extensive use of custom properties on DOM nodes. In particular for the following packages that introduce interaction behaviors:

D3 also provides a mechanism for putting your own custom properties on DOM elements called d3.local. The point of that utility is to generate property names that are guaranteed not to conflict with the DOM API.

The primary risk I can see associated with custom properties on DOM nodes is accidentally picking a name that already has some meaning in the DOM API. If you use d3.local or maybe prefix everything with __, that should avoid conflicts.

curran
  • 1,261
  • 13
  • 8