Re: Adding rows to a table, works in Firefox, but not IE

Marc Bradshaw wrote:
Richard Cornford wrote:
I have a table containing names and contact details for
customers. I have a <tbody> tag after my <table> tag, and
a </tbody> tag before my </table> tag, which I thought
meant that JavaScript in IE could then work with the table.

The tags themselves are optional in HTML. Omit them form the
mark-up and they will be implied, the opening tag by any TR
encounter outside a table section element (TBODY, THEAD and/or
TFOOT) and the closing one by the first subsequent occurrence
of a closing TABLE tag or opening table section tag.

How confusing. I only added the <tbody> tags in at the suggestion
of someone else that IE could not directly write to <table>
elements.

IE cannot append TR elements to TABLE elements, and errors if you try. But Mozilla/Friefox/Gecko cannot do so either in their HTML DOMs, the only difference is that if you try in those browsers they will 'correct' the mistake by automatically creating a new TBODY element, appending that to the TABLE element and then append your TR element to the new TBODY. To be honest I prefer IE's handling of this as it is up-front about letting you know that what you are attempting is not on.

The Mozilla/firefox issue is confused by XHTML, where a TR can be a direct child of a TABLE. Because no tags are optional in XHTML and they wanted some compatibility with HTML where the TBODY tags are optional and so the TBODY elements are (or can be) implied. That is, you can write both HTML and XHTML mark-up without THOBY tags, but the resulting DOM has a differing structure if you do.

<snip>
var cancelButton = null;
var saveButton = null;
var leftButtonDiv = null;
var rightButtonDiv = null;
var clearBothDiv = null;

why waste time assigning null to all these variables?

I was told it was good practice in JavaScript to declare
variables as null first, before assigning them values.
Is this not the case?

Total nonsense. It sounds like the sort of thing that might come form someone familiar(ish) with Java who has not understood that javascript is not Java (or even similar to it).

In javascript if you declare a variable it is automatically initialised with the undefined value (in javascript undefined is a value not a state). From then on the variable exists (as a named property of a Variable object) and has a determinable value (either the initial undefined value or a value subsequently assigned in code), until the Variable object it is created on becomes unavailable (mostly because the function in which the variable is declared returns) and gets garbage collected.

There are a huge number of things that get said about writing javascript, some of which are ladled 'best (or good) practices'. Unfortunately they include a great many things that are rumours, old-wife's tales and/or mystical incantations. They persist because, by and large, the do no perceivable harm, and the people promoting them never expose themselves to an environment where there is enough genuine knowledge to challenge them (or they don't listen when that does happen). This one is a mystical incantation; it does nothing useful, it does no notable harm, it just makes everything run just fractionally slower that it would if you didn't bother.

Generally, if someone proposes that something represents a 'best practice' in javascript you should read their explanation with _critical_ judgment, and if they don't explain, or cannot explain, then don't pay any attention. The noise-to-signal ratio is very high in this area.

space = function () { return document.createTextNode(' '); }

Where is - space - declared? If you want an inner function then
why not an inner function declaration?

Excuse my ignorance, but could you explain this comment please?
What is an inner function declaration?

An inner function declaration is a function declaration inside a function declaration. What you have here is a function expression assigned to an Identifier (space) that is undeclared (in this code). The result is that you can call the function that results from the evaluation of the function expression using - space() -, and you do. But if you use a function declaration:-

function space(){ return document.createTextNode(' '); }

- you end up with a function that you can call with - space() -. In both cases you create a new function object each time the containing method is executed (which is not a good idea given that this function has no interest in the context of its creation and so could be a single global function declared and created once). But one difference with using an inner function declaration here is that the resulting function cannot then be accessible outside of the containing method, which it is in your code, though seemingly not by design/need/intention.

<snip>
... . And without declaring a "contactsTable" variable locally
your assignment to it is an assignment to a property of the
global object.

Thank you for your explanation, I changed the variable name to 'contactsTbody' and because the ID of the <tbody> is
contactsTable, the code now works correctly. Is there a better
way to do this though?

Yes, declare the variable that you assign the value returned from - document.getelementById - as a function local variable (with - var - inside the containing function body (preferably at, or near, the beginning)) and your assignment will then never go anywhere near the global object, and so it will not matter at all what IE may have done to the global object.

I now have a <tbody> with an ID attribute of 'contactsTable'
which is referred to in my JavaScript as 'contactsTbody' which
I guess is not ideal for code readability and debugging.
<snip>

Not ideal, but not at all a difficult problem to solve. Suppose, for example, that you adopted a style of naming for ID attributes that used an initial uppercase letter, all upper case, or words separated with underscores, or anything that you never use in your javascript naming conventions. Then this type of thing cannot happen. Though with appropriate use of variable declarations it would not happen most of the time anyway.

Richard.

.