how to get the code line number of a dom element? - javascript

How can I find the code line number of a specific DOM element?
so I have a DOM element in a JS variable and I need a function that will return the code line number and the filename(path)


this is impossible since you can manipulate the dom.
two reasons:
the browser adds dom elements when parsing the dom (like <tbody> cause most people forget about it)
browsers also have auto correction of unclosed tags etc. etc. so viewing that it is impossible to define wich dom node is in wich line.
you can add / append / manupulate / delete dom nodes using javascript. the dom is not static. as soon as you do something like: var foo = document.createElement("div"); and append it to the body like: document.body.firstChild.appendChild(foo); the line numbers would logicaly change.
you can also move dom nodes around in the tree like changing the parent of an element etc.
you can also create dom nodes without appending them to the tree but you could append them in the later process.
simply said: you cannot figure out in wich line a dom node is unless you have an inspector installed (like rightclick to a node in the visual browser window and select something like "inspect element" in chrome)
every browser does different interpretation of html / dom so its impossible to have the same resulting tree.
the only thing you could do is adding a <script> tag that throws an exception. in most browsers you could then display the current line number through an alert box. (since i think thats "not a good idea" i will not go in details)

Related

Why does the value attribute from an input[text] is different from what the browser renders?

I'm getting this strange behaviour in a very specific set of inputs on one my applications. I create some inputs and I can see them as I created them on the Elements panel (google chrome), but the way the browser renders it is different.
Note how the input is renders with comma instead of a point, but the value attribute uses a point
When I get a referente to that element using the selector API, I get this:
A direct reference to the Dom Element will return 11,00. The tag has 11.00 and jQuery returns the 11,00. I've removed all js that interacts with this element (masks, events, etc) and the issue still happens.
I've been swearing at the DOM for a day and a half, but I know this is most probably an issue with my application. What bothers me the most is that the browser does not honor what I see in the elements panel.
This is the small piece of code that creates the element, stopped right before the tag is created. Note the variables values in the right panel:
Could someone give me a hint about what could be causing this difference in between element, view and attributes? If possible, I'd like to know what/how this is happening in depth.
Thank you in advance

Does updating innerHTML immediately update the DOM?

I'd like to add an element's HTML to a parent element and then immediately get the height of the parent element.
An example of what I want to do is:
parent.innerHTML += childHTML;
alert(parent.children[0].clientHeight);
This seems to work accurately in Chrome, but I know that JS is supposed to be single threaded, so in theory an implementation might have the DOM update after the thread has finished... but perhaps not?
Is it required to change the DOM immediately (at least in the way that I want it to), or does Chrome just use a convenient implementation?

Solution to get static script elements after dynamically appended elements

Within a web application I'm working on, in order to achieve the "app feel" - content being retrieved in the background instead of foreground - I'm using the appendChild() and removeChild() Javascript methods to append and remove elements as necessary. Doing so however, creates a small interference. Like as should be done, I place my script elements right before the closing body tag. But the appendChild() method (obviously as intended) appends child elements at the end, so some of the functions within the (now) above script tags process before its corresponding element even exists in the DOM.
So my question being, what should I do? I was thinking of simply placing a wrapper div inside of the body so I can keep the script tags at the end of the body. But is this the best solution? Is there anything easier, or maybe something to append elements into certain spots within the DOM?

is it possible to set a "watch" on an HTML element such that it hits a javascript debugger breakpoint when the HTML element changes?

Is it possible to set up a "listener" of some sort on an HTML element such that when this element is changed (perhaps by javascript / jQuery) the javascript debugger breaks on the line of code that changed it?
When my web page loads I see a list of "li" list item of text. Initially the text is legible,however, at some point there is some javascript/ jquery code that changes the list items to scrunch up together thus no longer making as easy to read.
is it possible to sort of "guard" these list items or make them read-only so that anything that tries to change them throws an exception?

In Chrome, you can do this by inspecting an element, and then in the Elements view, right click the DOM node you want to break on and select the desired behavior from the "Break on" menu.

Storage and retrieval of DOM element

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 comes 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 compare 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 accomplishing this are welcome!!
Thanks in advance everyone!

Here's a jsFiddle solution attempt: http://jsfiddle.net/techbubble/pJgyu/7720/
The approach I took was to compute 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 computed (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.org/TR/xpath/
http://www.w3schools.com/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, ;).

Categories