childNodes[0] probably contains a Text node in your case, containing the whitespace you almost certainly have between the table opening tag and it's first child element..
Also, a <table> has <tbody> before <tr> and mozilla will add that in the DOM even if it isn't in your source code.
__________________
"Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark
There are also <thead> and <tfoot>, but they're both optional.
What mozilla does is correct the DOM for you. IE doesn't do that. So the way to avoid conflict is to structure it the right way yourself.
I found out this way too
Incidentally - what liorean said still applies as well - the node you want may not be childNodes[0] if there's a whitespace text node in between. Using getElementsByTagName is one to find elements, or you can clean the whitespace yourself using a function like this one - http://www.codingforums.com/showthread.php?t=7028
__________________
"Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark
Last edited by brothercake; 05-14-2004 at 05:25 PM..
Well, it's got with te table model to do. The thead, tfoot and tbody elements are table row groups, meaning (surprisingly enough) that they group table rows together. They are in HTML required, but with start and end tags optional. See http://www.codingforums.com/showthread.php?p=152579 for some more detailed commentary I wrote about it.
IE accepts it as an array of TR's, Mozilla don't (when tested the lenght, Mozilla says I have 14 elements in array, while I have 7 rows)... That means the way objects are set up is wrong, from Moz's point of view, but I don't see which is that point...
here's the main function:
PHP Code:
function sortTable(col){
if (lastSort == col){
// sorting on same column twice = reverse sort order
absOrder ? absOrder = false : absOrder = true;
}
else{
absOrder = true;
}
lastSort = col;
allTR = document.getElementById('tableid').childNodes[0].childNodes;
// allTR now holds all the rows in the dataTable
totalRows = allTR.length;
colToSort = new Array() //holds all the cells in the column to sort
colArr = new Array() //holds all the rows that correspond to the sort cell
copyArr = new Array() //holds an original copy of the sort data to match to colArr
resultArr = new Array() //holds the output
allNums = true;
allDates = true;
alert(document.getElementById('tableid').childNodes[0].childNodes.length]);
//store the original data
//remember that the first row - [0] - has column headings
//so start with the second row - [1]
//and load the contents of the cell into the array that will be sorted
for (x=1; x < totalRows; x++){
colToSort[x-1] = setDataType(allTR[x].childNodes[col].innerHTML);
colArr[x-1] = allTR[x];
}
//make a copy of the original
for (x=0; x<colToSort.length; x++){
copyArr[x] = colToSort[x]
}
//sort the original data based on data type
if (allNums){
colToSort.sort(numberOrder)
}
else if (allDates){
colToSort.sort(dateOrder)
}
else{
colToSort.sort(textOrder)
}
//match copy to sorted
for(x=0; x<colToSort.length; x++){
for(y=0; y<copyArr.length; y++){
if (colToSort[x] == copyArr[y]){
boolListed = false;
//searcg the ouput array to make sure not to use duplicate rows
for(z=0; z<resultArr.length; z++){
if (resultArr[z]==y){
boolListed = true;
break;
}
}
if (!boolListed){
resultArr[x] = y;
break;
}
}
}
}
//now display the results - it is as simple as swapping rows
for (x=0; x<resultArr.length; x++){
allTR[x+1].swapNode(colArr[resultArr[x]])
}
}
...or even document.getElementById('tableid').rows Yes, this was the solution...
Yet I consider it a bug for Moz. If tbody can be an optional tag I don't think it must be or not taken in consideration as a compulsory Node. And even so, I still don't understand where from Mozilla invented double number of childNodes...
Mozilla isn't wrong on this. The DOM explicitly states that the browser should inject the TBODY element there. The thing is that in HTML4.01, the tbody element is required, but you may leave out both it's start tag and ints end tag. Meaning that when you write
because the tbody is required but doesn't need to be explicitly written out in the source code. So, what you're complaining about is actually HTML4.01, not the DOM. The DOM is just made to handle HTML and XML.
As for whitespace, Mozilla is arguably not wrong there either. You could argue that elements that may not contain #PCDATA should not contain Text nodes, but on the other hand, in XML, all consecutive whitespace should be concatenated to a single space, unless it happens to be significant. If you use CSS to change the presentation, you may make that space significant, which means that it hsould be there for display. Thus, all whitespace nodes should be in the element. If you need only elements, you have to filter the whitespace nodes out one way or another.
I agree... don't forget, XML parsers do not require a DTD nor Stylesheet to parse the XML. Neither XML nor DOM standards state that <TABLE> means "this thing is a table"; that is done at the stylesheet level.
Essentially, Web browsers have "built in style sheets" particular to HTML. You toss an HTML-like page at the browser, and it will do its best to render it. But in terms of DOM compliance, web browsers should comply with the DOM standard. No DOM processing engines, including those embedded in Web browsers, should apply unilateral, arbitrary, exceptions to DOM rules, like: "according to what I (the browser) know about HTML, there can't be text between something called "TR", so my DOM tree generation code will not consider certain characters I deem to be 'whitespace' characters between "TR" nodes as text nodes". Slippery slope!
Myself, after discovering this irritating difference between Mozilla and IE, decided that the script-generated HTML code on which my DOM scripts will act will have all the tags mashed together, inserting line feeds between selected attributes, inside the tags themselves, not between elements, so therefore no "whitespace text nodes" are created.
This solves the "extra nodes" problem, but in terms of markup legibility, darn it, does anyone know of a text editor that will "pretty print" XML on screen, according to nesting etc, without actually inserting whitespace characters? Just for debugging the generated markup....
Before you post, read our: 
DOM childNodes for Mozilla
