InnerHTML and Directory Creation: Browser Nightmares
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.
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
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!
innerHTML is faster than ‘real’ W3C DOM methods in all browsers. The W3C DOM table methods are slow to very slow, especially in Explorer."
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:
- It was just a Microsoft afterthought—let’s just patronize ol’ Bill and give it token support to be good sports.
- It’s not real DOM.
- It’s not W3C compliant.
- It inserts HTML code as strings rather than truly inserted nodes that work right.
- It’s weird.
- No one said "Simon says."
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.
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.
f.innerHTML="<DIV id='w' STYLE='z-index:2;background-color:transparent;position:absolute;padding:10px;border:1px solid black;border-bottom:"+dd+";top:344px;height:"+b+";left:
Printing was done from a window, and surprisingly, all browsers and platforms liked this code:
wi = window.open('', 'p')
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:
node.innerHTML="<DIV id='w' STYLE='z-index:2;background-color:transparent;position:absolute;padding:10px;border:1px solid black;top:344px; height:" + b + ";left:27px; width:778px;'></DIV>"
xx=3647+yy-(222 * name_f.length)
x=x.toString() + "px"
xx=xx.toString() + "px"
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:
r='<DIV class="record" id="'
rr='px";><DIV class="video"><img src="video-'
s='.jpg" border="0"></DIV><DIV class="photo"><img src="photo-'
t='.jpg" border="0"></DIV><DIV STYLE ="text-overflow : ellipsis; overflow : hidden" class="data" id="'
u='<BR><BR><B>EMAIL: </B><a href="mailto:'
w='</a><BR><BR><B>MYSPACE: </B><a HREF="http://'
ww='</a><BR><BR><B>WEB: </B><a HREF="http://'
oo='<BR><BR><B>' //before aa & gg
aa='For more details, hover over big photos.</B>'
zz=r + cc + rrr + b + rr + d + s + d + t + bb + uu + g + u + h + v + h + w + ii + v + ii + ww + i + v + i + y + oo + aa + gg + z
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!
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.