Brennan’s Blog

I was browsing my websites stats and noticed I was getting traffic from philringnalda.com. I am finding that sites which link to mine have a great deal of worthwhile content. So I am glad to find this website.

In a lot of ways it is a normal website, but if you wait for the page to load and then put your mouse pointer over the links on the top right it will provide a little surprise. Normally you can set the title attribute of a link and it will cause a tool tip to appear when your mouse is over the link, but this website uses Javascript to further enhance that ability. First it shows the title of the linked document and then the full URL. It is all displayed in a rounded container which is semi-transparent.

Now the beauty of this effect is that it provides a useful feature, but more importantly, if the Javascript fails and this effect does not work it does not detract from the functionality of the website. Kudos go to the author. Too many times I have been to websites which use poor Javascript to implement a critical field which eventually breaks the usability of the website.

So that brings me to the rules I follow when considering the use of Javascript:

• It must not break a critical feature of the website if it fails
• It must provide a usability benefit, not just a bell or whistle feature
• It must not be used if Javascript is not necessary for the effect
• It must not enforce complex business rules, especially timely rules
• It must be done with web standard coding so it is future-proof

The purpose of leaving complex business rules out of the Javascript is that you can relay data back to the server where it is much more feasible. You can use the XmlHttpRequest object explained in the Mozilla XML Extras Documentation or you can use an IFrame to implement a similar effect with hidden forms. It is simply better not to duplicate business logic in multiple locations to rely on Javascript to get it right. (You gotta believe me on this one.)

By making it future-proof it will require less maintenance. And when a new browser release comes out you will not have to scramble to make adjustments to support it. But how can something be future-proof if you cannot predict the future? Well, I have rules for that as well:

• Use web standard coding since they are planning ahead when you may not
• Do not root your code in a specific browser brand or version
• Use minimal code and Javascript features to get the job done
• Test it in many browsers on many platforms, at least the ones you support

Initially when Javascript first came out people were checking the version of Netscape to see if it was 3.x or 4.x but you can use a smarter means of checking the Javascript support by checking for methods. In Javascript calling a method without parentheses provides a boolean check to see if it exists. So you can use if (document.getElementById) { ... } to see if the browser at least supports the modern Javascript/DOM standard.

Check the head code at ESPN.com and notice how they make use of it. If the browser does not have the getElementById method it redirects the user's request to a page explaining to them that the website requires modern browser functionality and the user will need to upgrade to use the website. That baseline frees the website authors to use Javascript/DOM without backward compatiblity checks. And this is reasonable since less than 3% of web users are using the non-Javascript/DOM browsers and the specifications are now 4 years old and the newer browsers will support them going forward.

(FYI - Currently listening Prince sing Kiss on the iPod mini - Act your age not your shoe size, baby!)