Resident Evil - IE Browser Zombies

In the long-long-ago, I spent a lot of time developing rich interfaces for internet browsers using Javascript, tables, css, crazy image splicing and the ever increasing design requirements of my brother - a designer whose ignorance of technical limitations has been invaluable in the stretching and augmentation of my own skills. For over a decade I rode through the tumultuous browser wars, fanatical flame wars of html standards purists and varying degrees of pressures from both ignorant and savvy customers/clients/employers.

And then I discovered programmatic flash development. Slowly at first through beta Flex 1.0 and then a jaunt with Laszlo and now I am somewhat more fully engaged with Actionscript 3.0 and Flex. The road has been hard and fun, and the exploration of the Flash Platform threatens to provide a source of amusement and productivity for the forseeable future.

All of this is just a long-winded prelude as to why it is so difficult to go back "home". I am working on a DHTML project and I can say that I f@#*ing hate Internet Explorer. The depth of this disdain can only be appreciated by the thought that, with only 32 lines of Javascript, I have shredded the browser to the point where it no longer shows up in either the Windows Task Manager or even the Process Explorer. Effectively, I have a zombie IE window that will not go away absent restarting the whole OS - isn't that fantastic?

IE Zombies

image of zombie IE browser To create my undead browser windows, it only took a desire to change the characteristic of my page based on the size of the client window. If I have room in the browser, I can used position:fixed css positioning directives and treat the client area as a fixed position and fixed dimensioned interface (with a potentially annoying custom scrolling solution). If the room isn't there, I need to release the elements to a more fluid arrangement that allows the content to dictact the height of its container. This at least prevents the situation where a site visitor has to contend with browser scrolling and application scrolling.

So, the net effect is that, in the first case, the look is more like an application and in the second case, more like a regular page. You don't have to like this or agree with the design philosophy; I'm not even sure I am happy with it, even without the IE grief. However, this is just the background.

To accomplish this, I have neatly id-ed all my divs, and abstracted the CSS out of the page. The scripting attaches itself using the window.onload and window.onresize so content, look and behavior are all nicely abstracted from one another - a purist's wet dream I suppose. My code to handle my behavior is straightforward and executes cleanly in FF and Chrome:

function init() {
// Get handles for all the divs to be manipulated
divContentVerticalOffset = document.getElementById("pxl8_container_height");
divContentContainer = document.getElementById("pxl8_container_width");
divContentArea = document.getElementById("pixl8_content_content");
divHeader = document.getElementById("pxl8_header");
divFooter = document.getElementById("pxl8_footer")
divLogo = document.getElementById("pxl8_logo");
    
        
if (getWindowHeight() < 660 ) {
// This is the limited size scenario

// get rid of the custom scrolling
closeTabs("scroll");

// blowup the size of the content container to eliminate scrolling
divContentContainer.style.height = (divContentArea.scrollHeight + 50) + "px";

// change from "fixed" to enable page scrolling
divHeader.style.position = "absolute";
divContentVerticalOffset.style.position = "relative";
divFooter.style.position = "absolute";

// ensure the footer follows the content - 140 is just an offset to allow
// for the header and a little bit of aesthetic gap
divFooter.style.top = (parseInt(divContentContainer.style.height) + 140) + "px";

// let the logo, layered on header, to scroll as well
divLogo.style.position = "absolute";        
}
else {
// Plenty of space, behave like an application

// Since we are handling transitions from page to app, we need to make sure
// to account for any scrolling that might have occurred before a browser
// resize
window.scrollTo(0,0);

// resize the content area to the application size
divContentContainer.style.height = 500 + "px";

// secure the page elements to fixed positions    
divHeader.style.position = "fixed";
divContentVerticalOffset.style.position = "fixed";
divFooter.style.position = "fixed";

// in page mode, the top is set. Setting to null clears the value and
// prevents competing constraints.
divFooter.style.top = null;
divFooter.style.bottom = 0 + "px";
divLogo.style.position = "fixed";        
        
// If any content is obscurred, pop open the custom scrolling interface        
if (parseInt(divContentArea.scrollHeight) >
parseInt(divContentArea.clientHeight) ) {
openTabs("scroll");
}
}
}

Executing the above repeated times on my computer caused my own little Raccoon City problem to be solved only with similarly drastic means; Nukes, unfortunately, and not Alice/Milla Jovovich .. damn damn damn ...

Happy Ending

So, using the writing of this blog as a sort of debug/brainstorm session, I motivated myself to go line be line and find where the disaster was occurring. divContentVerticalOffset.style.position = "relative"; was apparently too much for the engine from Redmond. So, hours of my life washed away only to be redeemed by divContentVerticalOffset.style.position = "absolute";

This might be reasonable to someone - please tell me if your included in that set of people - but only goes to remind me of how awesome it is to be a AS/Flex developer.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1.001. Contact Blog Owner