A couple of notes: if you care about performance, use $.data(), i.e. instead of $('body').data(key, value) use
$.data(document.body, key, value).<p>Also .data() lets you access HTML5 data-* attributes. Note, that doing so values are converted to proper objects if possible. See <a href="http://jsfiddle.net/wLfJV/1/" rel="nofollow">http://jsfiddle.net/wLfJV/1/</a><p>Unrelated, but worth reminding: don't use $(this).attr('id')— this.id is simpler and much much faster: <a href="http://jsperf.com/el-attr-id-vs-el-id/2" rel="nofollow">http://jsperf.com/el-attr-id-vs-el-id/2</a>
Can anybody clarify the last line of the blog article [1]? The author makes it sound like storing data using $.data() is an async operation. The API docs make no mention of this. In some quick tests using Chrome, I was always able to immediately retrieve the value that was stored.<p>I'm actually planning on using this method, so I'd really like to know.<p>[1] "Furthermore, storing data takes a certain amount of time, so you might get a null exception if you are planning on retrieving it right after storage. There are currently no plans to add a callback to the jQuery data that I’m aware of."<p>Edit: $.data() seems to be async, but $(el).data() is not. At least that's what I found. Maybe that explains the difference in speeds.
I like to maintain a clean namespace, which means that generally, instead of recording data on DOM objects, I wrap it in closures. For those circumstances where I absolutely cannot do that (and it is rare), I try to be as local as I can and use a wrapper name...<p><pre><code> DOMObject.my_special_site_id.specific_data1
DOMObject.my_special_site_id.specific_data2
</code></pre>
Nasty global variableses...