Element in a td accessing parent <tr> element

[Christopher Benson-Manica]

I have an HTMLInputElement in a <td>. I want to access all the <td>'s
in the same row as the input element.

var tr=theInputElement.parentNode.parentNode;

Why isn't the input element's parent's parent the <tr> node in
Firefox? Internet Explorer seems to think so. How can I get the <tr>
node (so I can iterate through its children) in Firefox?

Why does this stuff have to be such a humongous god-forsaken
nightmare?? (sorry, working-late-bitterness)

 

[Matt Kruse]

var tr=theInputElement.parentNode.parentNode;

You can always use a general-purpose function like this:

function getParentByTagName(obj, tagName) {
tagName = tagName.toLowerCase();
while (obj!= null && obj.tagName!=null && obj.tagName.toLowerCase() !=
tagName) {
obj=obj.parentNode;
}
return obj;
}

then do:

var tr = getParentByTagName(theInputElement,"tr");

 

[Richard Cornford]

I have an HTMLInputElement in a <td>. I want to access
all the <td>'s in the same row as the input element.

var tr=theInputElement.parentNode.parentNode;

Why isn't the input element's parent's parent the <tr>
node in Firefox? Internet Explorer seems to think so.

In the DOM generated from valid HTML in Mozilla/Firefox the parent of
the parent of the child of a TD will be a TR. If that is not the case
then my guess (and it will have to be a guess because you have not
posted the mark-up with which the script is interacting) is that the
FORM element has been placed in an invalid location in the TABBLE and
you are experiencing differences in the DOM resulting from differences
in HTML error correction strategies. As no standards could be applied to
error-correction strategies, and the approach taken by any individual
browser (at least the commercial ones) are not published so cannot be
reproduced in other browsers, there is no reason to expect any two
browsers to generate structurally similar DOMs from invalid HTML.

How can I get the <tr> node (so I can
iterate through its children) in Firefox?

If the HTML is valid then Matt's approach will work, as should your
original. But if the HTML is not valid then Mozilla/Firefox's DOM will
be determined by the actual HTML used and no answer can be suggested
without seeing the mark-up.

Why does this stuff have to be such a humongous god-forsaken
nightmare?? (sorry, working-late-bitterness)

Problems in scripting that follow from invalid HTML are usually the
result of assuming that because various browsers happily display the
page in a more or less consistent way they will also produce
structurally similar DOMs from that mark-up. If the result is a
nightmare it is a nightmare of the authors own creation, and there is no
shortage of advice to use valid HTML when attempting to make cross
browser web pages (though it is often not made clear that it is in the
scripting of those web pages that value of valid mark-up is most
aparent).

Richard.

 

[Christopher Benson-Manica]

If the HTML is valid then Matt's approach will work, as should your
original. But if the HTML is not valid then Mozilla/Firefox's DOM will
be determined by the actual HTML used and no answer can be suggested
without seeing the mark-up.

The actual markup was a little too complicated to post. In any case
the markup passed the W3C validator, so I'm not sure what could have
been wrong with it. I appreciate your judicious response to my
frustration.