suggest a function that will spit out the dom path

[Jean Paul Sartre]

can anyone suggest a function that will spit out the dom path for an
object on id?
I'm having troubles targettting elements
so i thought, if i make a function that spits path (you send it id) then
it would help

html has:
<div name="nav"> <a href="yo">hey</a><p>this <h1 id="io">hey</h1></p></div>

i want to do something like
gdp('io');
and
print to alert or something.. something like

document.nav.io

you know?

(please no wisecracks about how that html example is invalid )

 

[Richard Cornford]

can anyone suggest a function that will spit out the
dom path for an object on id?
I'm having troubles targettting elements so i thought,
if i make a function that spits path (you send it id)
then it would help

html has:
<div name="nav"> <a href="yo">hey</a><p>this <h1
id="io">hey</h1></p></div>

i want to do something like
gdp('io');
and
print to alert or something.. something like

document.nav.io

you know?

Not really. No named properties of the document would be expected to
correspond with an (invalid) NAME attribute on a DIV, and that DIV
element would not be expected to have named properties that correspond
with ID attribute values on its children.

The properties that describe the relationship between elements in the
DOM tree are:-

firstChild
lastChild
nextSibling
previousSibling
parentNode

- and the:-

childNodes

- collection.

And in those terms the path between the document and any given element
may take many forms.

document.body.firstChild.firstChild.nextSibling

- might be the same element as:-

document.body.lastChild.previousSibling.childNodes[1]

While it is useful to be aware of the DOM tree structure it is rarely
useful to be interested in absolute paths from the document element to
its descendants. It is much more likely that you need to understand
acquiring and manipulating references to DOM nodes.

(please no wisecracks about how that html example
is invalid )

They are not wisecracks. It is important when scripting a DOM that the
HTML it is created from is valid. Your example is invalid in having a
superfluous closing P tag, but it is not the mark-up that the presence
of the closing P tag implies that you think it is.

A P element may not have block level emollients such as H1 as its
children, and the closing tag of a P element is optional and may be
omitted from the source code. So the browser reads your example HTML and
finds an H1 where it appears to be inside a P and, knowing that the P
cannot contain the H1, it is in a position to infer the closing P tag.
Later it encounters the superfluous second closing P tag, but as no P
element is open at that point it can error-correct that redundant tag
out of the DOM. Thus the mark-up you have presented is actually
equivalent to:-

<div><a href="yo">hey</a><p>this </p><h id="io">hey</h1></div>

- but what appeared to be a concept of an H1 contained in a P element
has turned out to be an H1 element that is the following sibling of a P
element and a direct child of a DIV element.

If your mark-up produces a DOM structure that does not correspond with
the structure that is the apparent intent of the mark-up then you will
encounter problems trying to navigate paths through your DOM. Because
you will not be scripting the DOM you think your are scripting.

Creating valid mark-up removes many of these considerations, and results
in constantly structured DOMs (particularly cross-browser, where
error-correction techniques differ). An HTML validator would have
complained about encountering a closing P tag when no P element was
open, and that would have been your clue that the DOM you would get from
the mark-up would not be the DOM you were expecting.

That a HTML validator would also complain about the DIV having a NAME
attribute then becomes you clue that attempting to reference that DIV
with that NAME value is not going to be at all successful cross-browser
(as some will disregard its existence).

Richard.

 

[Thomas 'PointedEars' Lahn]

can anyone suggest a function that will spit out the dom path for an
object on id?

(e-mail address removed)

 

[Lasse Reichstein Nielsen]

(e-mail address removed)

Or, alternatively:

function path(id) {
var elem = document.getElementById(id);
var path = [];
while (elem != document.documentElement) {
if (elem.previousSibling) {
path.push("nextSibling");
elem = elem.previousSibling;
} else {
path.push("firstChild");
elem = elem.parentNode;
}
}
path.push("document.documentElement");
return path.reverse().join(".");
}

This is just a suggestion. It expects the element to exist, the DOM
implementation to be standards compliant, and the browser to be in
standards mode. Also, it's quite stupid

A slightly more compact result is given by:
---
function path(id) {
var elem = document.getElementById(id);
var path = [];
var ci = 0;
while (elem != document.documentElement) {
if (elem.previousSibling) {
ci++;
elem = elem.previousSibling;
} else {
path.push("childNodes["+ci+"]");
ci = 0;
elem = elem.parentNode;
}
}
path.push("document.documentElement");
return path.reverse().join(".");
}

 

[Thomas 'PointedEars' Lahn]

(e-mail address removed)

Or, alternatively: [...]

Yes, of course. However, my point was that I do not intend to help
people (at least no second time) who disobey Internet standards (by
spoiling the global DNS namespace or abusing domains) and/or make
themselves unidentifyable by using ridiculous From headers). Funny
that my reply unintentionally bears another meaning that applies here
as well.


PointedEars