Laughing Otter Computing ServicesLaughing Otter Computing Services

Home » Business » HTML and all that »
Adventures Learning DOM Scripting
-OR-
If Someone Tells You the Browser Wars are Over, Don't You Believe It!

I had first heard of this marvelous new technology called AJAX (Asynchronous JavaScript and XML) before the end of 2005. It would enable pages to be able to make calls to the server without having to refresh the page the client was currently on. Several technologies are used in AJAX; JavaScript (which I knew, but not quite at the level needed), XML (which I already knew but used very seldom), and DOM Scripting. Ahh, here was something totally new, I thought, until I found out that that's what DHTML is called these days, and DHTML was DHELL for me last time I had attempted to do anything with it in 1999-2001 (especially since I had to make it work for both IE and Netscape-based browsers).

I'd had some progress until I ran into the issue of getting data back from the server. I thought it was something I'd been doing in Perl that was causing the non-return of data, so I did a version of the server component in PHP. Still, no returned data. When invoked as a separate process (as a query-stringed based URL), both returned well-formed XML documents. So the server component was NOT the problem, and I now had the heartening knowledge that I'd written two lingustically-different ways of doing the same thing...that left Java and ASP. Java's problem is its huge preprocessing overhead (how much of your system's resources it needs before it can start), so the only way Java would really make sense as an AJAX delivery system is if the entire application suite was written in Java. For such a simple return (like from the Pinball Locator) all of that overhead is not necessary. ASP...OK. Been a while since I did anything with ASP (the E-Carton Project), but I use it at work, and it may be migratable to the .NET platform if I get it right. (Translated: more job skills!)

Then I found out that the original suggested method for retrieving XML from the server using .documentElement was the problem. After reworking things so that .responseXML was the return method, I started getting actual results back!

However (again), this time it was Firefox that was having some issues regarding whitespace nodes returned in the body of the XML. Fortunately for me, AJAX For Dummies (which is probably the best AJAX 101 book out there) had a JavaScript function to remove these whitespace nodes from XML documents. And once I had done that, I was ready to parse my results! Just pass your .responseXML variable into this subroutine. No more whitespace nodes!

Wasn't that easy? Oh, yeah, there's a regular expression in that last bit. It's a fairly basic one, as far as they go. If you don't know about these yet, make sure your favorite language(s) support them. Dunno about IE, but nearly every Open Source language has regular expression support.

Now the results were appearing perfectly in Firefox. But once I looked at the same thing in Internet Exploiter I was left going "WTF?!?" Where the foosh did all my styles go? Why was the header all cramped in the first cell when I had stated a colspan value of 4?

Once again, IE was the problem. Both of them, in fact.

IE does not like the term "class", instead using the term "className". OK, this was an either/or case, so it was easy to make this function using an IE-only property, document.all. Here's the function:

where you would substitute the name of your element under construction for divThing, and your style class(es) where the word "hide" is. Not elegant, but it does work.

The second problem (and this one is not very well-documented) is the problem of attribute keyword case-sensitivity. Firefox, Mozilla, Opera, Safari, and pretty much all other browsers are not case-sensitive when it comes to attribute keywords. IE, however, is. I was pretty furious that because one letter in the keyword was not alphabetized, IE throws out the whole declaration.

So, here is a table of attributes for use with .setAttribute that (as far as I know) are cross-browser compatible:
accessKeytabIndexcodeBasenoHrefaLinkvLink
bgColorfgColorformNameclassNameframeBorderlongDesc
marginHeightmarginWidthnoResizecontentDocumentnoShadelowSrc
isMapuseMapdefaultValuedefaultCheckeddefaultSelectedmaxLength
readOnlyhttpEquivvalueTypechOffcolSpanrowSpan
noWrapcellPaddingcellSpacingtHeadtFoot 

But the adventure doesn't end there, oh no!

Now that styles and attributes were finally rendering more-or-less consistently across the different browsers, a new problem surfaced.

The program I was developing uses user-entered notes to further describe places and games. That could lead to some extremely large pages, so I used another technology to create some link-toggle boxes that would appear/disappear when its link was clicked. Firefox has no problems with dynamically-generated links, so the notes boxes could be opened and closed at will. (I'd done that partially with printing in mind. You could print exactly what you wanted to print by leaving the relevant notes boxes open and the others closed.)

IE loses something when it tries to generate a dynamic hyperlink that uses an onclick method. The link appears, it's underlined, the mouse pointer turns into a pointing hand when focused over the link, but when you click it, nothing happens. Nothing at all.

The solution to this tells me that the IE DOM still has some pretty severe problems. (understatement)
Tell me this ISN'T a hack:

Took me a few more days to figure out that in order to get that above bit of code to work in IE, a wrapper div needs to contain both the trigger link and the (hidden) notes div. OK. That I could handle. It's even logical.

However (again), the
document.getElementById("outFoo").innerHTML=linkThing;
construct only works if the element in question actually exists at the time. And since often during DOM scripting you have defined page elements that are not yet attached to the page, so at that time are not actually part of the document DOM tree, the .innerHTML property will not work.

To solve this, I would have to create a results row for the output table and send that out to the document; then double back, assemble the trigger link, blit that out to the now-existing wrapper div, then attach the hidden notes div.

Meaning yet another codebase revision...*sigh*

Next Chapter: Doubleback IE (sorry, Rutles)

IE DOM == Bad
Why Implementing the Internet Explorer Document Object Model in Mozilla is a Bad Idea

Pinball Locator