WebRef Update: Featured Article: Practicing Safe Code

Practicing Safe Code

Forward

One of toughest problems webmasters face is writing code that uses the best features of our visitors' browsers, while not knowing beforehand what software they are running. You can write branching code or redirects, but there are no easy server-side methods to tell if a user has turned off scripting in his 4+ browser. Have you looked at a page that uses positioning with a 3x browser? Not a pretty sight....

From a code writer's point of view, a user getting an error on their page is the worst thing that can happen. Designers feel the same way when their carefully positioned elements are presented to a visitor in source code order, rather than the way they intended. It doesn't really matter if 99% of all users have no problems. That last one percent is what keeps us up at night, wearing the letters off our keyboards.

There are some basics of defensive coding that make some of this a little less work.

Part 1: Always Work from the Simple to the Complex

Rather than using a script to try to identify and redirect a visitor who does not have the correct platform or browser to particular pages or scripts, use your script to add more sophisticated features. Imagine the visitor to your page has no script engine at all.

Start with a set of basic pages that can be viewed in the most technically challenged browsers. Your page headers can redirect the advanced browsers after reading the properties of their navigator object. The fancy code can be in pages that can't be clicked to directly, but instead are served up from scripted functions that only send the visitor on if he's got the right stuff.

You can set up some of your links like this:

A browser with no event handling ability will simply link to the URL without even trying the redirect function. A browser a bit more clever will run the function, which can be something like this:

function redirect(){ if(parseInt(navigator.appVersion)

The return false allows the default link behavior to return older browsers to the simple link, though if you want, you can have separate pages for any number of versions and browsers.

Just return the new links as true, as this function does for the version 4 and above browsers, to void the link's default behavior.

Part 2: Use the <NOSCRIPT> Element

Say you have a nicely defined set of pages for scriptless browsers. It's all carefully set up to avoid any links to the killer code you have for advanced visitors. There is still a pitfall that will give you a serious pain before you are through. It's called hypertext.

There is nothing to stop anyone from simply typing an address in their browser and crashing the party you have set up. Or clicking on a link someone e-mailed them, or coming in from a search engine. It's the nature of the Web. Also, a script in the head of every page that tries to weed out the unschooled won't work very well if they aren't running with the same script engine. Most likely they'll see a big mess with your name on it.

It won't do to ignore them - not if you want them to come back when their browsers grow up, or to stay for a while in the shallow end of your pool with the pages that play nicely with everyone.

The <noscript> element works by not being understood. Although it is intended to work in modern browsers by identifying an installed script engine version, the text and html between the opening and closing tags will show up in an older browser. I have a stock <noscript> sequence I put right after the body tag on any page that uses scripting:

A user with no scripting engine, or scripting turned off, will see these links at the top of the page. I put in a 1K pixel tall transparent gif to push the rest of the page's content a thousand pixels down - out of sight for most. Users with scripting enabled will see the page as intended.

Some scripted browsers, like Netscape 2, don't recognize <noscript> and show the content between the tags as if they had no scripting. I just let it go. Navigator 2 is best left to the history of the Internet, and the most basic of pages.

Next: Code Defensively and To Each His Own

This article originally appeared in the November 4, 1999 edition of the WebReference Update Newsletter.

Comments are welcome
Written by Kenneth Tibbetts and

Revised: May 16, 2000

URL: https://webreference.com/new/script.html

WebRef Update: Featured Article: Practicing Safe Code

Practicing Safe Code

Forward

Part 1: Always Work from the Simple to the Complex

Part 2: Use the <NOSCRIPT> Element

Find a programming school near you