Writing Friendly Code 4. Checking IDs | WebReference

Writing Friendly Code 4. Checking IDs

home / web / dev / friendly

Writing Friendly Code    

4. Checking IDs

On the way there we have already sniffed out the browser, if there is one. This is probably a familiar bit of code. The navigator object is not a part of the document object, so it can be read before a document loads fully by either major and most minor browsers. 

My goal is to keep the code out of the html, so the page can be as flexible as possible. If I identify a client browser that can take it, however, I am going to give it as much code as I please in the script.

The variable brid comes up a lot in branching code for IE and Navigator. I centralize some of it, but most of it is easy to handle inside the functions that need it.

if (parseInt(navigator.appVersion)>=4){ 
if (navigator.appName.indexOf("Microsoft")!=-1)brid="IE"; 
if (navigator.userAgent.indexOf("Mac")!=-1) Mac=true;
if (navigator.appName.indexOf("Navigator")!=-1) brid="NS"; 

I run this early because my infotips are browser specific, and they are assembled before the onload handler is called. Lots of times I have used a sniffer to location.replace() the document with a different one, based on the browser. I'm trying to not do that any more. Simplify, simplify...

Now we have parsed the code, which is a bit like choosing up sides and assigning positions in a pick up ball game. At the end of the script come the window event handlers, saying," Play Ball!"

1.d.Window event handlers

Actually they say:

if(brid=="NS")window.captureEvents(Event.RESIZE || Event.LOAD || Event.UNLOAD);

If you have a narrow screen, that line may break, but it has to be one line in the source. It looks at brid to see if it needs to handle any events for Navigator. IE doesn't know from layers. It's all the one window and all the events would work even if you didn't use the keyword "window" to call them. To IE, if you aren't in a frameset, there is only one window and one document. 

But Navigator treats positioned content as if it were separate documents. If you leave a window.onload call out on its own, every layer will call it as the various layers are loaded. If you have an uncaptured window.onresize for a page with a lot of layers, you'll resize and reload and reload again, till you run out of layers, or memory. Assign the Events for Navigator.

This isn't true, by the way, if you call the events from the body tag in the HTML. Then the top level document, what IE calls document.body, does the handling like it did since before layers were invented - about two weeks before they were deprecated....

When we get to the HTML, you'll notice I don't have anything called a "layer" on the web page, though I do in the script. Navigator interprets the divs, which are absolutely positioned by the stylesheet, as if they were named layers. I am doing my best to write valid HTML, and although the Layer tag won't break anything, it isn't gonna last.  Don't get me wrong - if the W3C had gone Navigator's way, I'd be using layers. This is about writing pages that will work in the widest variety of platforms, today and tomorrow. I'm damn sure not putting stuff in my code that I know isn't gonna last; what I don't know about is enough to keep me jumping. Anyway, I don't like window event handlers in the HTML. 

After I assign to the window the onload, onunload and onresize events in Navigator, I assign the handlers for any browser. Up to this point we can be in anything that reads JavaScript.

When the page is unloaded reStat() does some housekeeping on the way out. sizMan() handles window resizing, and also deals with Microsoft's idiot phantom scrollbars.  I thought they were gone forever, but they came back to make positioning more of a struggle. 

I have had more complaints about Navigator than IE so far, but believe me, between the two of them, there is no way to tell the evil twin.  Neither one can handle the current DOM 1 from the W3C, and don't even try them under DOM2.  Microsoft does its usual Borg-like assimilation to simulate most of it, but that is another story. We can make do - we have to. As long as we keep our code flexible, we'll be able to weather whatever comes next, and in the meantime, there are Web pages to produce. IE and Navigator are what we've got to work with today. Most people use some version of them, and there is no such thing as a bad dog.

if(brid=="NS")window.captureEvents(Event.RESIZE || Event.LOAD || Event.UNLOAD);

This starts the action...when the document loads, we go to isReddy(), who doesn't believe it. Mr. isReddy does not believe anything got loaded, and has to be convinced before we can go further into the program.

Environmentally Aware 

Comments are welcome


Created: Dec. 2, 1999
Revised: Dec. 7, 1999

URL: http://webreference.com/dev/friendly/