Gentrification

It's one thing to crow about the virtues of designing web sites using XHTML/CSS instead of HTML4 tables and JavaScript. It's another to go back to one of your own Frankenstein jobs and fix it.

The Bert Lauzon exhibit was one of two I inherited midstream from my predecessor, a talented graphic designer named Bob Lunday. Bob set the tone for what exhibits could look like. However, when he left NAU for W.L. Gore in late 1999, Dreamweaver 3 was teh hotness, and Web design was largely a matter of building tables.

• Websites were designed in Photoshop, chopped in ImageReady into tables and given over to DW for cleaning up the aftermath.
• JavaScript rollovers were everywhere, along with image preloaders. At a time when most people still had dialup connections I can't explain what we were smoking thinking.
  
• We were just beginning to figure out that using the LAYER tag wasn't such a good idea.
  
• CSS was used mainly for link text rollover effects in IE since Netscape wouldn't support it until 6.0 came out, and Netscape 4's CSS model was eight kinds of broken.
  
• We duplicated everything across every page — scripts, rudimentary CSS, BODY formatting, everything. Possible exception for long script modules.
  
• JavaScripts were written for Netscape 4 or IE 4, both of which used dialects soon to be obsolete, and browser sniffing and code forking was everywhere. DHTML authors were the only ones working on universal wrapper functions, which as they metastasized from functions into entire libraries, eventually became more of a problem than a solution.
  
• Most JavaScripts looked more like BASIC-Plus than object-oriented code because conceptually most script authors weren't coming from C++ or Java backgrounds and didn't recognize the potential or good programming practices.
  

While designing the exhibit, I was confronted with a handful of images too large for the screen but whose details zoomed in took the subject out of context. I opted for what was then a hot JavaScript item — a sliding magnifier pane. Superimposed over a thumbnail image is a pane you can drag around the screen to see a closeup of what's below. It's a combination of mouse event capturing and CSS image clipping that typically uses a separate image for the magnifier pane.

The magnifier pane is an excellent example of a concept not ready for the real world. Invariably the demos are on pages which aren't long enough to scroll, so the issue of dynamically calculating the offset of the pane from the thumbnail never comes into play.

Typically when I find a JS widget from someone else, there's a honeymoon period followed by the stark truth of how easily it breaks when just a few basic assumptions in the original design are challenged with real world requirements. Recently a charming little script for automatically checking/unchecking all the boxes in a form met the real-world problem of what happens when half those boxes are divided visually from the other half, but share the same NAME value (e.g. separate fieldsets). The code had to be rewritten to take a container ID and use a different method for collecting the INPUT objects.

Back to the magnifier pane. With the thumbnail in an unknown position, I had to rewrite the code to account for the pane's location. At the time, the 4.0 browsers were dominant. It would be nostalgic to say the differences in the dialects were mostly semantic; the truth is the object models diverged unpleasantly, and the dialects reflected different paradigms. My "force relative position" script in the body onload discovered each thumbnail's coordinates, then repositioned the pane relative to the thumbnail. This was complicated by the limitation that IE 4 only returned the coordinates of an HTML element relative to its container element, not the page, so if the image was in a table (like all of them are in the exhibit), the script had to be modified to take the container ID as well. If IE was detected the table's coordinates were determined instead and then the thumbnail's offset from the table was fudged to create the image coordinates.

In its 2000 incarnation, the magnifier pane breaks in all modern browsers, whose script engines expect DOM models for event capture, object referencing and style property names. This is actually a good thing. The challenge was finding a modernized version of the magnifier pane, since the original author seems to have forsaken it. Thankfully someone at Princeton either wrote or found a fix which cooperates in IE/Moz/Opera/Safari (but not in Konqueror). Its only drawback is that in IE under W2K the pane blanks while you drag it—most likely due to its method of overloading all BODY drag behaviors (thinking like OOP rather than procedural code). Under XP it's fine.

The rest of the Lauzon exhibit still requires reworking. Completed so far:

• 2-row, 1-column image/caption tables have been changed to 1-cell tables with CAPTION elements (not a perfect solution, but until HTML has rendered caption metadata for image tags this is it).
• JavaScript rollover image buttons are now completely CSS, utilizing a transparent IMG trick I recently developed (and haven't seen duplicated elsewhere). The default button image is a transparent single-pixel GIF stretched to the background image's dimensions; a hover behavior on the link overrides the background image. Cross browser compatible without csshover.
• The remaining table formatting is mostly replaced with CSS and more syntactically meaningful code. Bert Lauzon's diary entries are BLOCKQUOTEs.
• The image of W.W. Bass' classified newspaper advertisement has been given a LONGDESC pointing to a separate web page containing a reasonable simulation in CSS. I haven't seen any formal declarations stating that LONGDESC pages are supposed to avoid any CSS markup, so for now it isn't cheating.