Wondering if anyone out there has ran into this before....

I'd like to use JavaScript to identify a DOM element on a page, then store it's reference in a database or cookie for later retrieval.

To get specific, what I'm looking to do is create a UI so that when the user CLICKs an element on a page, JavaScript fires the click event, passing the instance of the DOM element clicked on.

easy so far, right?

So what I want to do is store the "identity" of this DOM element, say in a database, so when I later return to this page, I can pull out all stored DOM element identities and get access to them in the page once more.

So this is quite simple if this DOM element has a unique ID. Just store the ID, then when the page es back up, we just do a getElementByID and we've got our DOM element again.

The problem is that not everything in the DOM has a unique identifier, so there the problem lies.

I had some bad ideas initially, like iterating through the entire DOM and incrementing them with unique class names (dom-01, dom-02, etc) and this would give me an identifier. But this would cause a lot of initial overhead and if the page ever changed, the order of the DOM elements wouldn't be the same, so we wouldn't get back the correct DOM elemet.

I'mve never tried it, but another thought was to serialize the DOM element, stick it in the DB, and then on reload parse to an object, and use that object to find my original DOM element. I've never done that before, so how I can actually pare the restored (parsed) object to the one in the DOM is a big unknown.

Specifics on the serialization solution or any other original ideas for acplishing this are wele!!

Thanks in advance everyone!

Wondering if anyone out there has ran into this before....

I'd like to use JavaScript to identify a DOM element on a page, then store it's reference in a database or cookie for later retrieval.

To get specific, what I'm looking to do is create a UI so that when the user CLICKs an element on a page, JavaScript fires the click event, passing the instance of the DOM element clicked on.

easy so far, right?

So what I want to do is store the "identity" of this DOM element, say in a database, so when I later return to this page, I can pull out all stored DOM element identities and get access to them in the page once more.

So this is quite simple if this DOM element has a unique ID. Just store the ID, then when the page es back up, we just do a getElementByID and we've got our DOM element again.

The problem is that not everything in the DOM has a unique identifier, so there the problem lies.

I had some bad ideas initially, like iterating through the entire DOM and incrementing them with unique class names (dom-01, dom-02, etc) and this would give me an identifier. But this would cause a lot of initial overhead and if the page ever changed, the order of the DOM elements wouldn't be the same, so we wouldn't get back the correct DOM elemet.

I'mve never tried it, but another thought was to serialize the DOM element, stick it in the DB, and then on reload parse to an object, and use that object to find my original DOM element. I've never done that before, so how I can actually pare the restored (parsed) object to the one in the DOM is a big unknown.

Specifics on the serialization solution or any other original ideas for acplishing this are wele!!

Thanks in advance everyone!

• javascript
• dom

• 3 perhaps you should state the actual problem you are trying to solve... – Mitch Wheat Commented Mar 20, 2011 at 1:05
• 1 Agree with Mitch Wheat. Why are you trying to do such a thing? You are mixing presentation concerns (the ID of a DOM object) into your data storage layer. It's generally inadvisable to do so. – anon Commented Mar 20, 2011 at 1:12
• This is a very situational question as @mitch and @anon are eluding to. Providing a specific example will help a lot. – Bryan Downing Commented Mar 20, 2011 at 1:24
• @mitch and @anon - The second sentence of the post describes exactly what I'm looking to do "I'd like to use JavaScript to identify a DOM element on a page, then store it's reference in a database or cookie for later retrieval." Perhaps you should read more carefully. The "why" of the question is irrelevant as this is exactly what I am attempting to acplish. – clockworked247 Commented Mar 21, 2011 at 17:26
• @clockworked247 : actually, that's your perceived solution to a problem you haven't stated. " The "why" of the question is irrelevant as this is exactly what I am attempting to acplish" - with experience, you'll learn that the 'why?' is very important. More important certainly than remarks such as "Perhaps you should read more carefully" – Mitch Wheat Commented Mar 22, 2011 at 0:38

2 Answers 2

Here's a jsFiddle solution attempt: http://jsfiddle/techbubble/pJgyu/7720/

The approach I took was to pute a simple hash of the HTML content of the target element, or if no such content is present, a hash of the aggregated attributes and values of the element. I have a getElementHash() function that returns a string in the format: TAG:[H | A]:Hash (the H or A indicates if the HTML content or attributes were used to calculate the hash). This produces a unique key for any element on the page that either has HTML content or has at least one attribute (miniscule risk of duplication possible).

For retrieving an element with a previously saved key, I created a getElementByHash() function. It uses the tag that is extracted from the key in a jQuery selector. For each element returned, the HTML content or attributes hash is puted (based on the value "H" or "A" specified in the key) to see if it matches the hash in the key. If there is a match, the search ends and the element is returned.

This approach is impervious to the element being moved around on the page as long as its HTML content (or attributes) remain unchanged. It does not produce a key for elements that have neither any HTML content nor any attributes (which makes them pretty useless anyway).

If you want to keep the location of the node in the DOM, why not just keep an XPath of it? XPath allows you to keep an exact location of a node in a document, as long as that location doesn't change. For instance, you can say something like

//div[@id="xpath_is"]/span[class="cool"]/a[4]

Meaning the 4th <a> tag within a <span class="cool"> within a <div id="xpath_is">

http://www.w3/TR/xpath/
http://www.w3schools./xpath/default.asp

You can get the XPath of an attribute by Inspecting it with Firebug and right clicking on the node and selecting "Copy XPath". I'm not sure how easy it is to get it from a DOM Node (there are ways, but not sure how many baked implementations there are lying around). It'd be relatively easy to simply look for an ancestor (by traversing upward with .parentNode and building one) and adding .classNames and .ids as you go - but I'm too lazy to write this right now, ;).