Every corporate site that want to join in on the latest hypes, is moving to techniques like AJAX (all the non-corporate sites that want to join in on the hype, did so a year or more ago). If you have no idea what AJAX is about, then please disconnect your computer again, and enjoy your social life (you gotta have one, if you don't know what AJAX is about). Most sites want to retain backwards compatibility. Either because they actually care, or just because the consultant needed a few more bucks. Backwards compatibility with older browsers is a good thing, but usually implemented in a really bad way. Most sites fall back on a browsercheck, and match that against an internal list. This goes wrong either way. Either your textbased/ancient browser is not found on the list, and you get an unusable site, or your other-brand/brandnew browser is not found on the list, and you get a website that represents the earliest days of webdesign. Just don't rely on browserchecks. They don't work, or you need a full blown team that searches the net 24/7 for new and other browsers, their capabilities, and keep that list up to date. And even then I wouldn't rely on them. Don't rely on browser information either. Some browsers, mostly older ones, ly about what they are capable of handling. It's a commonly known fact, but you can't keep a list of all exceptions either. There is however a perfect way to tell if a browser is capable of handling AJAX (or: insert your favorite technique here). Read on...
The most perfect way, and this might sound utterly simple, is to have the browser prove it can handle it. Laugh as much as you want, and then listen some more. It does make sense. If you send some basic code to the browser that should perform an AJAX request if it could handle it, and then watch if the browser does actually make the request, you know for sure if the browser can handle it. Let me break it down for you:
1) Creating a testcase
In your HTML, most preferabely your footer, place a little bit of JavaScript. Put it as low as possible. The lower it is placed, the later it is executed. It's best placed on the very end of the HTML, just before the closing body tag. Once you opened your script block, insert an opening HTML comment tag, and a blank-line. Then open a try { } block, just to catch any exceptions thrown. Now, inside that try { } block, put your simple AJAX code. Just let it make a GET request. The browser will include the SESSION key, and that will help us handle the request. Close the javascript with an empty catch() { } block, a blank line again, the closing HTML comment tag, and the closing script tag. Now, we made a few things sure:
- If the browser doesn't handle javascript, the code does not get executed (the script tags)
- If the browser is really old, and doesn't handle javascript correctly, the code doesn't get executed (the HTML comment tags)
- If the browser generates a catchable exception, the code won't be executed (the try { } catch() { } block)
- If the browser generates an uncatchable exception, nothing else happens, as this was the last code on the page.
- If the browser is capable of hanling AJAX, and does everything as excepted, it will make the AJAX request.
2) Handling the proof
On the server-side, create a simple controller, that accepts the request, and updates, for example, the SESSION to indicate that the browser is indeed AJAX capable. Now, in following pages, you know that the user has AJAX enabled and you can make use of the extended functionallity created by Javascript, the XMLRequest object and the DOM. The browser proved it could handle AJAX, so you can trust the browser, for once (pun intended). If the browser never makes the request, the SESSION variable doesn't get set, and you could append the testcase again to the site. This works in all browsers, no matter which brand, no matter which year they were made, no matter what. (If you find any exception to this, please let me know, I tested anything I could lay my hands on)
3) Extending this example
There are many ways to extend this example. Like modifying your testcase to redirect to a new page which does have AJAX enabled. This does cause a reload (and you might want to move the testcase code into ) but does give the user the AJAX enabled website even on the first page. You could implement more tests into the testcase, just to see how far you can go with this browser, and so on. I'm not going to spoil all the fun. just get out there, and make the www a better place ;)
~RW
Post new comment