In reference to the creation of a web site with a directory that is based on JavaScript arrays stored in external .js files, let’s just say that if the browsers were all perfectly programmed, W3C compliant, bug-free, or at least if they listed all their serious bugs and gave workarounds, the task would be merely a neat challenge. But in actual fact, directory creation ran into piles of browser bugs and quirks and limitations and the very unwelcome Mac "pop-up safety" filters that crippled rerendering of records with JavaScript. Safari, in particular, when faced with record rendering JavaScript, and with search and sort routines, would just simply bomb—and this was scripting that IE5.5 and IE6.0 and Firefox and Mozilla and Netscape easily handled. And Opera didn’t bother to bomb when it encountered this scripting—it was too busy being insane. On an XP with Opera it displayed okay but events didn’t work, but the same code on Windows 98 on Opera made all the web display content line up vertically like soldiers waiting in a chow line! A Browser with under 1% of the market deserves supporting only if it is consistent and not a bugatorium, or at very least very similar to an existing popular browser like IE or Firefox. We ended up using an alert to urge Opera users to use IE or Firefox on the directory.

The following browsers required lots of hard work and experimentation to create workarounds for their bugs and quirks, but once this work was done, all three main functions of the directory (displaying record data and pictures, sorting, searching) were fully operational.

IE5.5
IE6.0
Firefox—recent 2006
Mozilla—recent 2006
Netscape—recent 2006

The following browsers were hopeless re: searching and sorting but we were able to get data and picture display to work fine. With the Mac Safari browser, once we got it fully functional it would crash after searches and sorts so we commented out these functions and let it do display only. With IE5 on the Mac, we not only couldn’t get it to search and sort due to its rerendering craziness, we were also unable to make record details pop up (as a result of the cursor hovering over the record) in a DIV superimposed upon the record being viewed. So in the OS 9 and OS X IE5 browser, we had to settle for clicking on the record and getting a new window, complete with scroll bar, which requires closing by hand—nothing automatic here.

Mac IE5 OS 9 on a G3
Mac IE5 OS X on a G3
Mac Safari—most recent one that works in a G3

Bug Swatting and Other Fun Activities

It’s sad, but here's a summary of how browsers responded to our directory JavaScript. Once challenged with code that would allow them to show their wondrous JavaScript handling capabilities, they either rolled over and played dead like lazy hound dogs or tried to do their job and fell on their faces. We've no idea how browsers other than those mentioned might respond to our code, nor do we care that much, but for a browser like Opera to have so much trouble and inconsistencies with scripts, and for it to blow up so flamboyantly, merely made us decide it would no longer be included in any web site testing regimens. The workarounds that the other 8 browsers needed were weird and not encouraging—but they were doable, if one was patient enough.

InnerHTML?—Oh, Ya Know, It’s Not Really W3C Compliant

Okay, guys, the jig is up! This is no excuse for supporting it so poorly! Most browsers will let coders use innerHTML for a few simple little operations like changing text in a paragraph, but woe be unto him who tries to really use the innerHTML property seriously!

In doing a directory that uses JavaScript arrays, properties, events, and methods to display records (and redisplay them after searches and sorts), the innerHTML property is essential. NodeValue and CreateTextNode properties are fine for text adding and changing but when HTML codes (lots of them) need to be in the mix, the idea of using W3C compliant straight DOM methods becomes formidable and—as anyone can find out with a few benchmark tests—very slow as well. JavaScript expert Peter-Paul Koch, in his Quirksmode site, says: "The most obvious conclusion of these tests is that innerHTML is faster than ‘real’ W3C DOM methods in all browsers. The W3C DOM table methods are slow to very slow, especially in Explorer."

Microsoft did a great thing inventing innerHTML, as it is one of the most useful and well supported (due to its great usefulness and ease of use) of all JavaScript properties. With so many sites using it, it’s browser suicide to fail to support it. So they all do. THAT’S the GOOD news. Now for the BAD news.

THEY SUPPORT IT LIKE CRAP!

The even worse news is that even IE supports it poorly! So why the rotten support and why all the bugs in the type of support browsers give to this wonderfully useful little innerHTML command? Excuses:

1. It was just a Microsoft afterthought—let’s just patronize ol’ Bill and give it token support to be good sports.
2. It’s not real DOM.
3. It’s not W3C compliant.
4. It inserts HTML code as strings rather than truly inserted nodes that work right.
5. It’s weird.
6. No one said "Simon says."

Since all these excuses except the last two seem to have a tad of validity, let’s look at them, with the exception of 5 and 6, which you have permission to ignore: Excuses 2 and 3 turn out to be copouts since the DOM needed this property very much for completeness, ease of use, more capability, speed of execution, and just common sense. We’re all quick enough to put down Bill’s Boys when they goof up—how about we give them credit when they do something very smart!? In actual fact, no matter what anyone tells you, innerHTML was a serious JavaScript need nearly from the start, and the fact that it was omitted from W3C DOM specs was an error that Bill’s Boys rightly cured and most JavaScript coders are very grateful about that! The W3C and DOM think tanks should have immediately embraced it and incorporated it into official W3C DOM immediately rather than turning up their noses and acting like it was a fifth leg on a dog. In incorporating it, they should have described how to implement it so it takes the new code and adds it to official page node content so the code can actually function reliably and predictably.

Oh, on simple pages "innerHTML Lite" works—where you replace a sentence and don’t have real node ramifications. But "innerHTML Serious"—that’s another matter!

Let’s look at the facts: we want our DOM to be about DYNAMIC web page changes, creation, manipulation, and creativity. Normal, official DOM is great stuff and does all this nicely, but innerHTML is even more the essence of what the DOM/DHTML is about than official DOM/DHTML! All that were needed were clean implementation specs and the web world scripters would have been happier than pigs in poop! But what happened? Apparently, the W3C were embarrassed they didn’t think of it first. So they kept it as an "outsider" and as a result the browser coders implemented it sketchily, stupidly, with little insight or foresight, and, above all, buggily!

This apparently disconcerted or distracted Bill’s Boys so much that rather than finishing their implementation so the innerHTML properties became incorporated as deeply as other nodes being tracked by the browser, they kept their implementation superficial, thereby losing a great opportunity to be a great example to other browser coders re: the immense potentials of their wonderful innerHTML invention! Shame on them, and shame on ALL the browser makers and the W3C for a classic missed opportunity. What our experience has shown us is that the innerHTML implementation among browsers and platforms is chaotic, inconsistent, and misunderstood. The purists curse innerHTML’s birth but hypocritically bewail the slowness and huge amount of code needed to do what innerHTML does swiftly and with a line or two of code.

There needs to be a book written that describes exactly how to implement innerHTML in a cross-browser and cross-platform context that includes IE5.5 and IE6 and IE7, Firefox, Mozilla, Netscape, and Mac IE5 (OS 9 and OS X) and Mac Safari. (These are the only ones we test on, and if we say "worked on all browsers and platforms," below, we’re referring to these only. We haven't had a chance to add IE7 to our testing browsers yet as of September 2006—but we soon will. The book should address this browser too. Our experience casts doubt on the value of worrying about Opera—but if anyone can figure out a consistent innerHTML strategy for it, that should be in the book too.) As it is, implementations are so buggy and inconsistent that coders have to experiment and hope to get lucky, when for the rest of their JavaScript they depend on skill, logic, experience, and insight.

Methodology

Important CSS style, link and image name details had to be in the strings that got put into each record’s innerHTML property. Normal DOM methods and properties were user where reasonable. Below we are fixing a bug of a missing div bottom border that IE had, but Firefox, Netscape and Mozilla did not.

Printing was done from a window, and surprisingly, all browsers and platforms liked this code:

Appending child nodes was done as normally as possible—this worked on all browsers and platforms:

And removing the divs before a sort was likewise normal DOM:

One div height display bug was so serious in IE that it needed for the screen to scroll up and down for a microsecond in order to deal with it:

In order to squash the notorious IE z-index bug during record display, we had to add an extra div (w) to hold all the records, and each time records are recreated, we recreated a sibling (w) to main parent div k at z-index level –1 and made it transparent and then put background-colored div boxes on all 4 sides of the central block of displayed records (data and images)—talk about Mickey Mouse! Once again, normal DOM methods were employed where possible; all the next code block was for IE only due to its div z-index and innerHTML bugs—other browsers didn’t need any of this:

Strings were gotten from arrays in a .js file and concatenated into a long HTML-containing string that was dumped into the innerHTML property (partial code only shown here)—this worked in all browsers and platforms:

When the cursor hovers on a record, the full details of the record are shown on a div that pops up on top of the record. This involved taking a div that was hidden at left:-800px and moving it 822 pixels rightwards to left:22px. Mac IE5 was having none of it—it screamed until we were forced to use window pop-ups and replace pop-ups activated with hovering with mouse-click activation.

The onKeyPress event is something that was needed to give visitors a convenient way to keep a pop-up popped while they scrolled the scrollbar examining record details on the pop-up. But the Mac only lets coders use this if the visitor is doing "legitimate" keyboard-based input like text or select. The Apple Developers site confirms this. The Firefox/Mozilla/Netscape trio sang an even lamer song: it wouldn’t pick up key hits until a mouse click had occurred first. We cured this, but, are embarrassed to admit—we have no idea how. It just suddenly started behaving on all these browsers, and we’d been working on fine-tuning styles with DOM, not events at all. If anyone can shed any light on this strange Gecko behavior or any workarounds for Apple deafness to key hits unconnected to keyboard input, we’d be glad to hear about it!

Summary

One would think that the amount of createElement, appendChild(), setAttribute, parentNode.removeChild() and removeAttribute() methods (there was lots more than shown) used would have done a more consistent job of fixing the incompleteness of how the innerHTML property does its thing. But browsers were all over the map on their needs in this area and the Mac was abysmal. The way IE5 Mac simply wouldn’t redisplay records (after search or sort) once they’d been put on the page made us see that they were trying to "protect us from pop-ups," as nothing else explains such egregious IE Mac incompetence. Mac’s "protection" seemed to cover all potential pop-up methods, including the use of negative left positions, display: none, visibility: hidden, onLoad used like a true user-controlled event, rerendering anything, and anything with even the slightest taste of innerHTML—apparently equivalent to Satan to Mac browsers. Perhaps it’s just a lia-Bill-ity in their eyes. The Safari browser didn’t even have an "excuse." It just simply crashed after search or sort so on all Windows browsers there are search and sort routines but Mac has neither. More careful innerHTML implementation is likely the key here for Mac browsers.

Which brings us once again to our main thesis: The only GOOD way out of the innerHTML chaos, bugs, and frustration that reflect so poorly on all involved, is inclusion of innerHTML in official W3C DOM—complete with clear implementation specs that include treating the HTML codes dumped into the innerHTML property as legitimate codes, and divs or other objects added or revamped with innerHTML added to the document as legitimate nodes. How many years was the W3C planning to give short shrift to this singularly valuable JavaScript property? Or, put more sagely: sometimes one doesn’t find enlightenment with one’s head in the sand—sometimes one finds only . . . sand.