Scheduling JavaScript: Another Way to onLoad
December 22, 2005 @ 06:12 pm
During the development of the new Gaia Online layout, one of the most challenging things was the dependancy on two separate servers. In the case of Gaia, all images, CSS, and JS are served from the graphics.gaiaonline.com domain, while PHP and HTML and processed on the www side. This wouldn't have been much of a problem if the inline calls to the JavaScript weren't beating the loading of the JS from the header. In the occasional time when this happened, the header would chuck a wobbly and revert back to the Suckerfish Style dropdowns. So, initialization was paired back up with their respective source, and we began researching into ways to [listen" for html elements to exist and be ready for replacement.
It turns out there was more than just HTML elements we needed to listen to however. Knowing that the browser got the JS files in order became important when the load balancer would hand the request off to a possibly different machine for each JS file. And so began the research. The base of the code actually is derived from Cameron Adams' piece on "JavaScript load placement](http://www.themaninblue.com/writing/perspective/2004/09/29/.) One of the issues mentioned in the commnets is that Safari doesn't necessarily know proper height and width, even when the object nodes exist. This caused sIFR some problems when it couldn't generate a flash object of the proper size. Michael Palacios suggested using attributes such as 100% since we can see and predict scalability in an SWF when it's the only thing in a browser window. Unlike traditional sIFR, the generated node is uncaring of its height and width, instead adopting a [100%" of the containing div element for width and height. This non-semantic div can then be styled, letting the flash inside of it scale appropriately. If you'd like, you can browse the prototype (very primitive) below. I mention it primarily because it is a way to solve the repaint problem in browsers. Because the height and width are always at 100%, the dependancy for scaling is moved out of the node creation and into the ActionScript itself.…