In the course of about two and a half hours yesterday afternoon, I hacked together a fixed version of KPMG.com. It works consistently in Gecko-based browsers and Internet Explorer for both Macintosh and Windows (at least in IE5.5/Win, which is what I have). This despite the fact that my version does no browser sniffing at all: the same scripts are handed to whatever browser comes to visit. I would have posted all this yesterday, except KPMG’s Web site (from which I pull all the images) went offline yesterday afternoon, just as I uploaded my fixed version. Weird.
My fix is not, I should point out, a full makeover into total standards-compliant code and markup. I left the poorly structured HTML more or less alone, save for the minimal changes I had to make to get the page cross-browser savvy, like converting name attributes to id attributes. Similarly, I touched only those pieces of the Javascript that needed to be changed. And I didn’t try to make the DHTML effects more efficient, or speed them up for Gecko, whose dynamic performance still lags behind Explorer. Thus in Gecko-based browsers the effects will seem sluggish. Nevertheless, they do work and the page does lay out correctly in the Explorer and Gecko families, which is a heck of a lot more than we can say for the actual site. I don’t know about other browsers because, in all honesty, I was only willing to sink so much time into a non-paying project.
As I say, this took me about 150 minutes to accomplish, and it would have been less if I hadn’t had to research DOM-compliant event handling (thank to kirun for hooking me up with the answer!). Remember, I’m a CSS guru, not a DOM and Javascript expert, so it took me longer to figure everything out. A full makeover to a no-font, minimal-table, optimized, and fully DOM-based script version would have taken a couple of days, most likely. Add another day to make the way the page is put together rational, since right now the way the script routines fit together is a little frightening. And there are other problems with the site, like serving CSS files with the MIME type application/x-pointplus, but those seem like incidentals. Correction: kpmg.com’s CSS files are in fact served up as text/css; it’s kpmg.ca‘s CSS files that are the wrong MIME type. My apologies to the server adminsitrator(s) at kpmg.com for my incorrect assertion.
In total, a complete makeover lasting three days would still be—even at top-drawer consultancy rates—around US$6000. Compared to what the site probably cost to develop badly, that’s an amazing bargain. If even one customer using, oh, let’s say AOL for OS X, was able to browse the site and decided to sign a contract with KPMG, the work would more than pay for itself.
Oh, and I almost forgot: KPMG.com has been broken for well over a year now, as detailed in Bugzilla entry 83846. We know from that entry that KPMG got e-mail about the problem on 10 July 2001.
With any luck, they’ll take the work I’ve done and use it, seeing how as I’ve written them and offered it at no charge. Feel free to add your own voice to the process; you could even use the contact form on the fixed version, and if you’re using a Gecko browser, you’ll have to since the actual KPMG site is, you know, broken in your browser. If they’re afraid of what it might do in Explorer, they could still use their server-side sniffing to give any Gecko agent the fixed version (DevEdge has a good article on Gecko detection). Of course, I think they should just offer up a standards-based site as the default, but hey, I’m only one guy. No doubt a large corporation that couldn’t fix its own site problems knows far better than I do. Hmmm… was that too bitter?