Supporting all browsers

There was a time in the web's infancy where I would write javascript to determine which browser the end user was using. Doing so consisted of testing each browser and version. These days I use the jQuery $.support action. For example:

var someDocumentObject = document.getElementById('somePieceOfContent');
if($.support.leadingWhitespace)
{ someDocumentObject.style.leadingWhitespace= "top"; }
else
{ someDocumentObject.style.someStyleElement = "top"; }

If we check the property leadingWhitespace then we can check to see if it is supported by the user's browser. If not, we can use some style element that we know will work for browsers that don't support this property.

This won't fix all browser compatibility issues but it does help with a few of them.

Why I would not use jQuery

In the pursuit of remaining impartial and fair lets briefly go over why we wouldn't want to consider using javascript for our web project. The first main argument that I hear or read is the size of the page. That it adds to much to the size to the downloaded page. This may be true, I mean how long does it take to download 56Kb of code? It can take up to maybe 10 seconds on a 56Kb modem or slower. So I can see where this may be a valid argument.

Then there is the load that it requires to run it on older browsers. Generally one could consider this to be a factor or hardware compiling the end user software. This will usually involve a machine that is at least 7 to 10 years old and running on antiquated browser environments.

I've also read that languages like JAVA or scripting languages are better at manipulating the DOM and adding effects.

In general it helps to always consider alternative ways of solving the same problem. JavaScript is an advantageous alternative to other environments, but not the only one.

What you might think to disable when writing for iPhone's

A lot of the handlers for iPhone or Droid usually get triggered twice for both touch and mouse events. Often this will cause the algorithm to be run more than once when you may have only intended to run it once. When writing code I find it important to disable the default actions for mousedown and mouseup. Let's look at an example:

$document.bind('touchstart', function(e)
{ var someCapturedHandler = e.preventDefault; }

By capturing the handlers for mouseUp and mouseDown we can disable them and prevent the accidental execution of code when we meant to only run it once.

Some quirky things about calling attr

Often when calling the attr action in jQuery you use the attr(someKey, someValue) action, which generally is used to set attributes to some value. While we typically expect this value to be static, the attr action allows us to pass in a function to determine the value. Typically the function will need to be passed two parameters. The first being the index of the current element and its corresponding value. Where whatever the function returns for a value is what the attr action sets for the elements new value.

This type of dynamic processing took me a little while to get used to, but once you get it the possibilities are great. You can run this on a whole stack of commands like val, html, and others. This can make it very easy to change your DOM elements based on changing criteria rather than relying on a static template. Rarely does anything static last in the internet these days...