Started working on a new project with a new colleague the other day, and we decided to use JSON to handle the data client-side and standard W3C DOM scripting to represent the data, because all modern browsers support it (for about 95% that is), right?
During development we encountered those other 5% of which support was flawed, in Internet Explorer 6 (the usual suspect) and Firefox, the kind of things you most likely don’t read about in the books (well, I haven’t). This entry is just a write-up of those problems and their solution.
Let’s not start with the usual suspect IE, but with a genuine Firefox bug (Bugzilla Bug 26179). DOM has some read-only properties to traverse the node tree, like firstChild, lastChild and childNodes. This last one returns an array of childnodes for a specified node, and therefore you can also call the length property of this array. In our case, this resulted in a difference in length between IE and Firefox. What was going on here (tip: source formatting)?
We had a table (the proper way, for representing tabular data) with a tbody, and tr/th/td elements. If you don’t add a tbody element yourself, the browser is so kind to add one herself, which is in fact the standard behavior, so no finger-pointing here (again, if you didn’t take this into account during your DOM scripting, you might get another result than expected because of the browser adding a tbody element). We knew how many elements we had for the tbody parent, still there was a difference of 2 between IE and Firefox. This is where you need a DOM inspector. You get one in Firefox (included in the install) and you can get another one for IE (if you don’t have one yet, get the Microsoft Web Developer toolbar which includes a DOMi).Our table code was formatted as followed (simplyfied):
Because of this nicely formatted source code, Firefox adds additional textnodes, rendering the childNodes property useless for scripting. This is an example, try it with Firefox and IE. If you click the links, you’ll get the childNodes array lenth. Then also check the page using the DOM inspector for either browser.
This is the Mozilla explanation/solution.
My solution woul be to remove the whitespaces between tag, and format the source code differently, something like:
You get the idea, I guess.
I needed to add some blank content to a table cell, which would later then be replaced by actual content, Normally we would use a HTML element. WIthout content the table cell isn’t styled properly. To add this using domscripting you need to use the createTextNode, but using " " as its text content, it would be HTML encoded, being displayed exactly like that, You need to use the Unicode variant (u00a0), ex. as followed: