First of all, if you’re thinking this post is going to discuss the merits of being able to reach your cleaning products, then you should probably stop reading now or go and read about Ajax as defined by a propeller-head. If you’ve been following the meteoric rise of this asynchronous web development technique then you may have heard rumblings about it’s accessibility problems and solutions based on the idea of progressive enhancement, unoffically known as Hijax.
I’ve been playing with Ajax as much as possible in my personal endeavours, however in my work here at education.au the priority is accessibility, so any potential usability enhancements Ajax could offer occasionally fall by the wayside. Of course, the Hijax term has been coined for over a year now, and long before that the idea of using client-side scripts with a server-side failsafe has been used in everything from image manipulation to form validation.
So why haven’t I used Hijax in any projects yet? The answer lies deep in the annals of my web designer history, back when Netscape 4.x was the web designers Sword of a thousand truths and Internet Explorer a magical portal to dynamic scripting sorcery (funnily enough, the XML over HTTP control already existed then, but that’s a different story). This may sound like some magical faraway land, but it was more real than you can imagine. So real, in fact, that on many occasions I was involved in projects that ended up with two almost completely separate interface codebases: one for Netscape 4.x and one for IE 4+. All because either a client or self-hating lead developer refused to cater to the lowest common denominator.
So as much as I’d love to get excited about progressive enhancement of web applications with Hijax, the thought of building two different blocks of code, to ultimately perform the same task, gives me nightmares…
Post a Comment